The future of Linux32 builds and tests

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: The future of Linux32 builds and tests

Axel Hecht
On 10/9/15 4:21 PM, Robert Kaiser wrote:

> [hidden email] schrieb:
>> According to Telemetry, Linux has about 0.2% market share on Desktop,
>> which means Windows has around 500X more users.
>
> That number does not look right. Our ADI numbers say that 3.5% of our
> overall ADI are on Linux. Given that a number of Linux distros may
> switch off Telemetry and FHR by default, but leave the add-on blocklist
> enabled (where ADI comes from), I'd trust that number some more - even
> with the flaws that the ADI measurement might have.
>
> That said, the fact that Linux distros might switch off Telemetry and
> FHR by default causes issues right in that way: they are undercounted
> and we may disregard them completely in data-driven decisions. If you
> are a Linux distro package manager, think about that.
>
> KaiRo
>

Note, even if telemetry was enabled, it'd be switched off by default, right?

In particular with linux, would we expect a "usual as on windows" opt-in
ratio for telemetry?

I still think we should have them, as they're part of our overall user
base, but I'm not sure if numbers behind opt-in are going to be as
reliable for linux as they'd be on, say Windows.

Axel
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of Linux32 builds and tests

Robert Kaiser
Axel Hecht schrieb:
> Note, even if telemetry was enabled, it'd be switched off by default,
> right?

In release, yes. In Nightly, Dev Edition, and Beta, it should be on by
default. But I guess the distros usually ship release anyhow. :)

> In particular with linux, would we expect a "usual as on windows" opt-in
> ratio for telemetry?

I don't know.

KaiRo
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of Linux32 builds and tests

Mike Hommey
In reply to this post by William Lachance-2
On Fri, Oct 09, 2015 at 12:21:26PM -0400, William Lachance wrote:

> On 15-10-08 09:40 PM, Mike Hommey wrote:
> >Debian is likely not very indicative of the overall Linux world. Taking
> >the primarily available figures from Debian and Ubuntu give completely
> >opposite pictures:
> >debian: i386: 51859, amd64: 132362
> >ubuntu: i386: 2065695, amd64: 673565
> >
> >(from popcon.ubuntu.com and popcon.debian.org)
>
> Are those Ubuntu numbers for installations in general, or Firefox
> specifically? I couldn't find out how to get architecture specific
> information from popcon, and I'm worried that the overall results include
> server installations (which would really skew them):
>
> http://popcon.ubuntu.com/main/index.html

For both Debian and Ubuntu, you can't get per-package architecture
split, but you can start from this, from the Ubuntu data:
- the total number of submissions is 2747796
- the sum of i386 + amd64 is 2739260, which leaves us with 8536
  submissions from other architectures.
- the number of submissions with Firefox is 2503536.

Even if 100% of the amd64 and other non-i386 architectures
submissions were with Firefox, that still would leave 1821435 i386
submissions with Firefox, which is still a whole lot more than the
amd64 ones.

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of Linux32 builds and tests

Ryan VanderMeulen
In reply to this post by Kim Moir-2
On 10/8/2015 1:01 PM, [hidden email] wrote:

> We recently disabled Linux32 talos testing on all trees.
>
> Going forward, the question remains, do we need to run Linux32 tests at all?  This would reduce the complexity of our configs, as well as significantly reduce our AWS bill. Do the linux32 test results provide significant differences from the ones we run on on linux64? I see three options going forward
>
> 1) Run linux32 builds and tests periodically
> 2) Turn off tests but run the builds and make it a Tier 2 platform
> 3) Turn off Linux32 builds + tests entirely
>
> Your data-driven input is sought,
>
> cheers,
> Kim
>
> Bugs of note
> Disable all 32-bit linux testing
> https://bugzilla.mozilla.org/show_bug.cgi?id=1209932
> Do we need linux32 talos?
> https://bugzilla.mozilla.org/show_bug.cgi?id=1204920
> Disable linux32 talos testing and reimage machines for windows testing
> https://bugzilla.mozilla.org/show_bug.cgi?id=1208449
>

Note that SM(arm) builds run on linux32 build slaves (and AFAIK, they
have to). Not sure where SM builds fit in with all of this, but I
figured it was at least worth explicitly calling out.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of Linux32 builds and tests

Steve Fink-4
On 10/12/2015 08:21 AM, Ryan VanderMeulen wrote:

> On 10/8/2015 1:01 PM, [hidden email] wrote:
>> We recently disabled Linux32 talos testing on all trees.
>>
>> Going forward, the question remains, do we need to run Linux32 tests
>> at all?  This would reduce the complexity of our configs, as well as
>> significantly reduce our AWS bill. Do the linux32 test results
>> provide significant differences from the ones we run on on linux64? I
>> see three options going forward
>>
>> 1) Run linux32 builds and tests periodically
>> 2) Turn off tests but run the builds and make it a Tier 2 platform
>> 3) Turn off Linux32 builds + tests entirely
>>
>> Your data-driven input is sought,
>>
>> cheers,
>> Kim
>>
>> Bugs of note
>> Disable all 32-bit linux testing
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1209932
>> Do we need linux32 talos?
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1204920
>> Disable linux32 talos testing and reimage machines for windows testing
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1208449
>>
>
> Note that SM(arm) builds run on linux32 build slaves (and AFAIK, they
> have to). Not sure where SM builds fit in with all of this, but I
> figured it was at least worth explicitly calling out.

I don't *think* they have to, since they run fine on my local (linux64)
box. But cross-compilation always confuses me.

When I run it locally, the arm-sim build (aka SM(arm)) uses my 64-bit
gcc with -m32 to generate a 32-bit JS shell whose JIT generates 32-bit
ARM code, and then runs it via a 32-bit ARM simulator. (I think that
rest of the shell would be fine if it were compiled as 64-bit, but the
simulator part only works when compiled as 32-bit x86 code?)

Like I said, cross-compilation is confusing, especially when you mix in
JIT and a simulator.

Also note that as of very recently there is an SM(arm64) build, which is
64-bit all the way through (including generating ARM64 code). But that
does not replace the need for the 32-bit ARM simulator. Generally
speaking, we can't just ditch 32-bit architectures entirely because we
need to be able to run on 32-bit ARM devices for the foreseeable future.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of Linux32 builds and tests

Jed Davis
In reply to this post by Daniel Holbert-3
Chris Coulson <[hidden email]> writes:

> On 09/10/15 02:01, Daniel Holbert wrote:
>> So, it seems we aren't getting telemetry from Ubuntu users at least. So,
>> unless we're getting platform info some other way (AUS pings?), sounds
>> like we can't be sure about 32-vs-64 market share without talking to
>> distros.
>
> I'm not sure I can provide any better metrics. You get blocklist pings
> from us though, don't you? Do these provide a useful metric?

For reference, we also get FHR data from Ubuntu's Firefoxes.  (I know
Debian disables FHR in Iceweasel, however; other distributions I haven't
checked.)  The main question in this thread seems to have been
effectively answered by the popcon data, but in general it's worth
keeping FHR in mind for things like this, where generalizing from the
prerelease population doesn't work.

--Jed
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The future of Linux32 builds and tests

Terrence Cole-3
In reply to this post by Steve Fink-4
On Mon, Oct 12, 2015 at 9:56 AM, Steve Fink <[hidden email]> wrote:

> On 10/12/2015 08:21 AM, Ryan VanderMeulen wrote:
>
>> On 10/8/2015 1:01 PM, [hidden email] wrote:
>>
>>> We recently disabled Linux32 talos testing on all trees.
>>>
>>> Going forward, the question remains, do we need to run Linux32 tests at
>>> all?  This would reduce the complexity of our configs, as well as
>>> significantly reduce our AWS bill. Do the linux32 test results provide
>>> significant differences from the ones we run on on linux64? I see three
>>> options going forward
>>>
>>> 1) Run linux32 builds and tests periodically
>>> 2) Turn off tests but run the builds and make it a Tier 2 platform
>>> 3) Turn off Linux32 builds + tests entirely
>>>
>>> Your data-driven input is sought,
>>>
>>> cheers,
>>> Kim
>>>
>>> Bugs of note
>>> Disable all 32-bit linux testing
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1209932
>>> Do we need linux32 talos?
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1204920
>>> Disable linux32 talos testing and reimage machines for windows testing
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1208449
>>>
>>>
>> Note that SM(arm) builds run on linux32 build slaves (and AFAIK, they
>> have to). Not sure where SM builds fit in with all of this, but I figured
>> it was at least worth explicitly calling out.
>>
>
> I don't *think* they have to, since they run fine on my local (linux64)
> box. But cross-compilation always confuses me.
>
> When I run it locally, the arm-sim build (aka SM(arm)) uses my 64-bit gcc
> with -m32 to generate a 32-bit JS shell whose JIT generates 32-bit ARM
> code, and then runs it via a 32-bit ARM simulator. (I think that rest of
> the shell would be fine if it were compiled as 64-bit, but the simulator
> part only works when compiled as 32-bit x86 code?)
>

32bit arches use a different Value packing format than 64bit. The JITs
assume at a very low level that Values (and values in general) have the
same layout and alignment requirements everywhere. As Steve noted, however,
cross compilation with -m32 works just fine.


> Like I said, cross-compilation is confusing, especially when you mix in
> JIT and a simulator.
>
> Also note that as of very recently there is an SM(arm64) build, which is
> 64-bit all the way through (including generating ARM64 code). But that does
> not replace the need for the 32-bit ARM simulator. Generally speaking, we
> can't just ditch 32-bit architectures entirely because we need to be able
> to run on 32-bit ARM devices for the foreseeable future.
>
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12