Re: Phabricator and Bugzilla

2018-03-31 Thread Mark Côté 
Regarding comment and flag mirroring, we've discussed this before:

https://groups.google.com/d/msg/mozilla.dev.platform/Y8kInYxo8UU/e3Pi-_FpBgAJ
https://groups.google.com/d/msg/mozilla.dev.platform/Y8kInYxo8UU/tsF7UfxvBgAJ

Given that Phabricator is still new, I don't see any reason to reopen that 
discussion at this point, aside from noting that we have work in progress to 
include Phabricator requests in BMO's My Dashboard and notifications indicator 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1440828).

As for interdiffs, feel free to file a bug with any problems you see.  We have 
a good relationship with upstream and can pass those on.  Similarly with method 
names (which has been mentioned before but I can't find where at the moment).

There is official documentation at 
https://secure.phabricator.com/book/phabricator/ which is linked from our 
Mozilla-specific docs 
(http://moz-conduit.readthedocs.io/en/latest/phabricator-user.html) which in 
turn is linked in the left-hand menu in Phabricator.  We can expand our own 
docs as needed if there are areas that are particularly confusing due to, say, 
expectations carried over from our other code-review tools.

Mark

On Thursday, 29 March 2018 13:45:28 UTC-4, smaug  wrote:
> Hi all,
> 
> just some random notes about Phabricator.
> 
> I've been reviewing now a bunch of patches in Phabricator and the initial 
> feeling from
> reviewer's point of view is that it is ok. Not great, but ok.
> MozReview's interdiff, when it works, is easier to use or at least to 
> discover than Phabricator's.
> MozReview does also show the method name in which the code lives. This latter 
> thing is actually a big
> + to MozReview. (Same works in Bugzilla too when reviewing raw -P patches at 
> least. No idea about splinter, since I never use it).
> If Pabricator has the feature, I haven't found it yet - its UI is a tad 
> confusing occasionally.
> 
> What is currently rather broken is the flag synchronization between bugzilla 
> and Phabricator.  One doesn't see in Bugzilla whether review has been 
> asked or whether review has been denied (r-). I believe people asking reviews 
> from me set the r? flag manually in bugzilla.
> Having an easy way to see that r- has been given to a patch is very valuable 
> to the reviewer when looking at the bug again.
> Oddly enough, approving the patch in Phabricator does set r+ in Bugzilla.
> 
> Not mirroring comments from Phabricator to Bugzilla has already made 
> following reasoning for certain code changes harder.
> It is so easy to include non-code level information in review comments. So 
> far I haven't had a case where I would have needed to look at the blame and
> try to find relevant information both in bugzilla and in phabricator, but 
> that will obviously happen if we don't do the mirroring and it will slow
> down reviewing in the future (since looking at the history/reasoning for the 
> code changes is a big part of code reviewing).
> 
> I'm sure I haven't found all the tricks Phabricator has to help reviewing. Is 
> there some reviewing-in-Phabricator-for-dummies doc?
> 
> 
> I haven't asked reviews in Phabricator (nor in MozReview), so can't comment 
> on how they compare from patch author's point of view.
> 
> 
> 
> br,
> 
> 
> 
> -Olli

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CPU core count game!

2018-03-31 Thread Steve Fink 
Yes, sorry, a couple of people pointed that out to me privately. And I 
did get that mixed up; I was assuming processors, despite the page 
specifically pointing out "physical cores".


I still think there's something to be kept in mind here, though. Even 
with 4 processors (2 hyperthreaded cores or whatever), it's never 
correct to assume that running something on a different thread is a gold 
bullet for performance problems. I'm all for increasing the concurrency 
of our code as long as we ensure that it doesn't hurt in the case of low 
levels of actual parallelism.


What that means in practice, I'm not entirely sure, but it does seem 
like we should be more conscious about thread priorities and global 
thread pool management. Also, lock contention is a real thing. It has 
been coming up here and there and wiping out parallelization gains.



On 3/28/18 10:27 AM, Ben Kelly wrote:
That page says "physical cores", so its not taking into account hyper 
threading, right?  So even a high end macbook pro falls in that category?


On Tue, Mar 27, 2018 at 5:02 PM, Mike Conley > wrote:


Thanks for drawing attention to this, sfink.

This is likely to become more important as we continue to scale up our
parallelization with content processes and threads.

On 21 March 2018 at 14:54, Steve Fink > wrote:

> Just to drive home a point, let's play a game.
>
> First, guesstimate what percentage of our users have systems
with 2 or
> fewer cores.
>
> Then visit
https://hardware.metrics.mozilla.com/#goto-cpu-and-memory
 to
> check your guess.
>
> (I didn't say it was a *fun* game.)
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-platform

>
___
dev-platform mailing list
dev-platform@lists.mozilla.org 
https://lists.mozilla.org/listinfo/dev-platform





___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CPU core count game!

2018-03-31 Thread William Lachance 
I don't believe these counts take into account the number of usage hours 
of each client, so people with 4+ cores may actually account for a 
larger amount of relative Firefox usage than their absolute numbers 
would suggest.


I am sure some people on the data / analyst / product side of Firefox 
have explored this issue (usage hours is reported on every ping), though 
I don't know if they monitor this list.


Will

On 2018-03-27 5:02 PM, Mike Conley wrote:

Thanks for drawing attention to this, sfink.

This is likely to become more important as we continue to scale up our
parallelization with content processes and threads.

On 21 March 2018 at 14:54, Steve Fink  wrote:


Just to drive home a point, let's play a game.

First, guesstimate what percentage of our users have systems with 2 or
fewer cores.

Then visit https://hardware.metrics.mozilla.com/#goto-cpu-and-memory to
check your guess.

(I didn't say it was a *fun* game.)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How much do we care about pre-Nehalem performance?

2018-03-31 Thread Henri Sivonen 
On Tue, Mar 27, 2018 at 1:36 PM, Henri Sivonen  wrote:
> Do we have numbers of how our installed base is split between earlier
> than Nehalem/Silvermont/Bulldozer vs. Nehalem/Silvermont/Bulldozer or
> later?

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1449496

I'd appreciate it if a CPUID expert reviewed the query I requested in the bug.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CPU core count game!

2018-03-31 Thread Ben Kelly 
That page says "physical cores", so its not taking into account hyper
threading, right?  So even a high end macbook pro falls in that category?

On Tue, Mar 27, 2018 at 5:02 PM, Mike Conley  wrote:

> Thanks for drawing attention to this, sfink.
>
> This is likely to become more important as we continue to scale up our
> parallelization with content processes and threads.
>
> On 21 March 2018 at 14:54, Steve Fink  wrote:
>
> > Just to drive home a point, let's play a game.
> >
> > First, guesstimate what percentage of our users have systems with 2 or
> > fewer cores.
> >
> > Then visit https://hardware.metrics.mozilla.com/#goto-cpu-and-memory to
> > check your guess.
> >
> > (I didn't say it was a *fun* game.)
> >
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unprefix: ::-moz-selection.

2018-03-31 Thread Emilio Cobos Álvarez 


On 03/28/2018 12:09 AM, twisniew...@mozilla.com wrote:
> On Tuesday, March 27, 2018 at 4:38:56 PM UTC-4, Emilio Cobos Álvarez wrote:
>> That looks like an easy fix though, I'll ensure it gets fixed before 
>> landing. Filed bug 1449010.
>  
> If it helps, I had a patchset for this in bug 292563, but ran into an odd 
> reftest failure that I never had time to figure out.

Ah, I see, interesting!

I used negative reftests (!=) to test this, instead of just trying to
overlay the image, which looks a little bit more fragile.

Given my patch just landed, I'll dupe that bug. Thanks!

 -- Emilio

> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CPU core count game!

2018-03-31 Thread Jeff Gilbert 
Are these actual "physical cores", or is this "hardware threads"?
There's very big difference between 2 and 2+HT these days.

On Tue, Mar 27, 2018 at 2:02 PM, Mike Conley  wrote:
> Thanks for drawing attention to this, sfink.
>
> This is likely to become more important as we continue to scale up our
> parallelization with content processes and threads.
>
> On 21 March 2018 at 14:54, Steve Fink  wrote:
>
>> Just to drive home a point, let's play a game.
>>
>> First, guesstimate what percentage of our users have systems with 2 or
>> fewer cores.
>>
>> Then visit https://hardware.metrics.mozilla.com/#goto-cpu-and-memory to
>> check your guess.
>>
>> (I didn't say it was a *fun* game.)
>>
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CPU core count game!

2018-03-31 Thread Joshua Cranmer  

On 3/27/2018 5:02 PM, Mike Conley wrote:

Thanks for drawing attention to this, sfink.

This is likely to become more important as we continue to scale up our
parallelization with content processes and threads.


How do these counts classify SMT systems (aka Hyperthreading)? Would 4 
core * 2-way SMT show up us 4 cores or 8 cores?


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Unaligned NEON memory access on ARMv7 phones

2018-03-31 Thread Henri Sivonen 
On Thu, Mar 29, 2018 at 4:09 AM, Makoto Kato  wrote:
> Since SCTLR isn't allowed on userland, there is no way to detect unalignment
> access support without trap.  Generally, unalignement access causes SIGBUS,
> so we might get a data from crash reporter.  Android armv7-a ABI doesn't
> define that hardware configuration has to set alignment bit of SCTLR, so we
> should consider both unfortunately.

To my surprise, clang 6.0 is willing to generate vld1.8 when no
particular CPU model is specified:
https://godbolt.org/g/i5PqcQ

Is unaligned NEON allowed on any ARMv7 CPU without trapping after all
even if unaligned ALU loads/stores might not be?

> ARM document of Cortex-A8 says [*1], alignment identifier is 64
> (VLD2.16@64), it requires 2 cycles, but alignment identifier is 128
> (VLD2.16@128), it is 1 cycle.  And on Cortex-A9, unalignment access requires
> additional cycles [*2].
...
> [*1]
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344h/ch16s06s07.html
> [*2]
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344h/ch16s06s07.html

Thank you. Was [*2] meant to be a different URL?

On Wed, Mar 28, 2018 at 6:36 PM, Gregory Szorc  wrote:
> Is
> http://fastcompression.blogspot.fr/2015/08/accessing-unaligned-memory.html
> and/or the comments for MEM_FORCE_MEMORY_ACCESS at
> https://github.com/facebook/zstd/blob/dev/lib/common/mem.h useful?

Thanks, but unfortunately these don't address my issue. These are
about getting GCC to perform an unaligned load efficiently when the
programmer has already decided to want an unaligned load.

I'm trying to figure out whether it's worthwhile to spend cycles to
move pointers to alignment if possible or whether it makes sense to
just use unaligned operations unconditionally. (Also, GCC doesn't
matter in my case, since I'm planning Rust code.)

In non-ARMv7 cases my findings are that moving to alignment doesn't
look empirically worthwhile on aarch64 (tested RPi3 and ThunderX,
which both have in-order cores; should test an out-of-order core, but
documentation supports the empirical results) or on Haswell
(documentation indicates that the key is Nehalem or newer). On Core 2
Duo, moving to alignment is worthwhile.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Unaligned NEON memory access on ARMv7 phones

2018-03-31 Thread Makoto Kato 
Since SCTLR isn't allowed on userland, there is no way to detect
unalignment access support without trap.  Generally, unalignement access
causes SIGBUS, so we might get a data from crash reporter.  Android armv7-a
ABI doesn't define that hardware configuration has to set alignment bit of
SCTLR, so we should consider both unfortunately.

ARM document of Cortex-A8 says [*1], alignment identifier is 64 (VLD2.16@64),
it requires 2 cycles, but alignment identifier is 128 (VLD2.16@128), it is
1 cycle.  And on Cortex-A9, unalignment access requires additional cycles
[*2].

When I was investigating string issue, I created a benchmark result for
optimization on Cortex-A7.  So I will look for this data.


-- Makoto

[*1]
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344h/ch16s06s07.html
[*2]
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344h/ch16s06s07.html

On Tue, Mar 27, 2018 at 7:44 PM, Henri Sivonen  wrote:

> I'm having trouble finding reliable information about the performance
> of unaligned NEON memory access on ARMv7 phones.
>
> What I can find is:
>
>  * ARMv7 seems to allow unaligned access to be a trap-to-kernel kind
> of performance disaster, but it's hard to find information about
> whether the phone SoCs we care about are actually disastrous like
> that.
>
>  * On aarch64, unaligned access is the same instruction as aligned
> access and gets dynamically penalized, but only minimally, if the
> access crosses a cache line boundary. *Presumably* ARMv7 code running
> on an ARMv8 core gets the same benefit.
>
> Do we know what performance characteristics we can assume for
> unaligned NEON loads/stores on Android phones that have ARMv7 cores
> and recent enough Android that Fennec runs in the first place?
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CPU core count game!

2018-03-31 Thread David Durst 
Just noting that there's bug 1399962 right now -- and if you're single core
(like a large portion of very affordable PCs in the past two years or so),
the problem can be so bad (bug 1431835) that common sites like amazon can
turn Firefox into a not viable option.

--
David Durst [:ddurst]

On Tue, Mar 27, 2018 at 5:02 PM, Mike Conley  wrote:

> Thanks for drawing attention to this, sfink.
>
> This is likely to become more important as we continue to scale up our
> parallelization with content processes and threads.
>
> On 21 March 2018 at 14:54, Steve Fink  wrote:
>
> > Just to drive home a point, let's play a game.
> >
> > First, guesstimate what percentage of our users have systems with 2 or
> > fewer cores.
> >
> > Then visit https://hardware.metrics.mozilla.com/#goto-cpu-and-memory to
> > check your guess.
> >
> > (I didn't say it was a *fun* game.)
> >
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Phabricator and Bugzilla

2018-03-31 Thread smaug 

Hi all,

just some random notes about Phabricator.

I've been reviewing now a bunch of patches in Phabricator and the initial 
feeling from
reviewer's point of view is that it is ok. Not great, but ok.
MozReview's interdiff, when it works, is easier to use or at least to discover 
than Phabricator's.
MozReview does also show the method name in which the code lives. This latter 
thing is actually a big
+ to MozReview. (Same works in Bugzilla too when reviewing raw -P patches at 
least. No idea about splinter, since I never use it).
If Pabricator has the feature, I haven't found it yet - its UI is a tad 
confusing occasionally.

What is currently rather broken is the flag synchronization between bugzilla and Phabricator.  One doesn't see in Bugzilla whether review has been 
asked or whether review has been denied (r-). I believe people asking reviews from me set the r? flag manually in bugzilla.

Having an easy way to see that r- has been given to a patch is very valuable to 
the reviewer when looking at the bug again.
Oddly enough, approving the patch in Phabricator does set r+ in Bugzilla.

Not mirroring comments from Phabricator to Bugzilla has already made following 
reasoning for certain code changes harder.
It is so easy to include non-code level information in review comments. So far 
I haven't had a case where I would have needed to look at the blame and
try to find relevant information both in bugzilla and in phabricator, but that 
will obviously happen if we don't do the mirroring and it will slow
down reviewing in the future (since looking at the history/reasoning for the 
code changes is a big part of code reviewing).

I'm sure I haven't found all the tricks Phabricator has to help reviewing. Is 
there some reviewing-in-Phabricator-for-dummies doc?


I haven't asked reviews in Phabricator (nor in MozReview), so can't comment on 
how they compare from patch author's point of view.



br,



-Olli
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unprefix grid-gap, grid-row-gap, and grid-column-gap and updating them to spec

2018-03-31 Thread Mats Palmgren 

Hi,

In bug 1398482 I'm unprefixing the grid-gap, grid-row-gap, and
grid-column-gap properties.  The old names becomes aliases for
the respective unprefixed property.
I'm also adding support for the 'normal' keyword to these properties
and making it the initial value, per spec [1].

I'm also adding support for percentages to the existing unprefixed
column-gap property (which is only supported in multi-column layout
until now) in bug 1398537.  It already supports 'normal', so with
these changes it has the same syntax as the updated grid-column-gap
property so we can now "merge" them.

These properties also applies to Flexbox:
https://drafts.csswg.org/css-align-3/#gap-flex
We haven't implemented layout for that yet[2], so one could argue
that we shouldn't unprefix the grid-* properties until we do.
I think we should anyway, for two reasons:
1. Chrome decided to ship them[3] without Flexbox layout support,
   so it will likely lead to Grid web-compat issues soon unless we
   do the same
2. column-gap is already in the wild, so the problem already exists
   for this property with the spec generalizing it to Grid/Flexbox


/Mats

[1]
https://drafts.csswg.org/css-align-3/#column-row-gap

[2]
https://bugzilla.mozilla.org/show_bug.cgi?id=1398483

[3]
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/UViBfJuuIq8/w7_2W7lLAgAJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Remove: privacy.firstparty.isolate.restrict_opener_access

2018-03-31 Thread Tom Ritter 
privacy.firstparty.isolate.restrict_opener_access is a pref for First
Party Isolation that relaxes the protections of FPI by allowing access
to window.opener across first party domains.

It was created because in Tor Browser's initial FPI patch, they
allowed this by mistake, and we wanted to keep backwards
compatibility.

Except it was ever actually used; although it did solve at least one
FPI login breakage flow that relied on that opener access.

Since it's been used in practice by anyone we know of, and it
complicated some codepaths, we intend to remove it.

-tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Core i9 Workstation or Dell Workstation now in the Catalog

2018-03-31 Thread Sophana "Soap" Aik 
Hellol Dev-platform,

These are now added to the catalog.

Core i9 Workstation:

https://mozilla.service-now.com/sp?id=sc_cat_item_id=
56a3f19d13895f407b5450782244b00e


Dell Workstation

https://mozilla.service-now.com/sp?id=sc_cat_item_id=4bfc7195138d5f407b5450782244b00b


Thanks


-- 
moz://a
Sophana "Soap" Aik
IT Vendor Management Analyst
IRC/Slack: soap
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform