On Tue, Jul 17, 2018 at 03:49:41PM -0700, Jeff Gilbert wrote:
We should totally be able to afford the very low cost of a
rarely-contended lock. What's going on that causes uncached pref reads
to show up so hot in profiles? Do we have a list of problematic pref
keys?
So, at the moment, we read about 10,000 preferences at startup in debug
builds. That number is probably slightly lower in non-debug builds, bug we
don't collect stats there. We're working on reducing that number (which is
why we collect statistics in the first place), but for now, it's still
quite high.
As for the cost of locks... On my machine, in a tight loop, the cost of a
entering and exiting MutexAutoLock is about 37ns. This is pretty close to
ideal circumstances, on a single core of a very fast CPU, with very fast
RAM, everything cached, and no contention. If we could extrapolate that to
normal usage, it would be about a third of a ms of additional overhead for
startup. I've fought hard enough for 1ms startup time improvements, but
*shrug*, if it were that simple, it might be acceptable.
But I have no reason to think the lock would be rarely contended. We read
preferences *a lot*, and if we allowed access from background threads, I
have no doubt that we would start reading them a lot from background
threads in addition to reading them a lot from the main thread.
And that would mean, in addition to lock contention, cache contention and
potentially even NUMA issues. Those last two apply to atomic var caches
too, but at least they generally apply only to the specific var caches
being accessed off-thread, rather than pref look-ups in general.
Maybe we could get away with it at first, as long as off-thread usage
remains low. But long term, I think it would be a performance foot-gun.
And, paradoxically, the less foot-gunny it is, the less useful it probably
is, too. If we're only using it off-thread in a few places, and don't have
to worry about contention, why are we bothering with locking and off-thread
access in the first place?
On Tue, Jul 17, 2018 at 8:57 AM, Kris Maglione <kmagli...@mozilla.com>
wrote:
On Tue, Jul 17, 2018 at 02:06:48PM +0100, Jonathan Kew wrote:
On 13/07/2018 21:37, Kris Maglione wrote:
tl;dr: A major change to the architecture preference service has just
landed, so please be on the lookout for regressions.
We've been working for the last few weeks on rearchitecting the
preference service to work better in our current and future
multi-process
configurations, and those changes have just landed in bug 1471025.
Looks like a great step forward!
While we're thinking about the prefs service, is there any possibility
we
could enable off-main-thread access to preferences?
I think the chances of that are pretty close to 0, but I'll defer to
Nick.
We definitely can't afford the locking overhead—preference look-ups
already
show up in profiles without it. And even the current limited exception
that
we grant Stylo while it has the main thread blocked causes problems (bug
1474789), since it makes it impossible to update statistics for those
reads,
or switch to Robin Hood hashing (which would make our hash tables much
smaller and more efficient, but requires read operations to be able to
move
entries).
I am aware that in simple cases, this can be achieved via the
StaticPrefsList; by defining a VARCACHE_PREF there, I can read its value
from other threads. But this doesn't help in my use case, where I need
another thread to be able to query an extensible set of pref names that
are
not fully known at compile time.
Currently, it looks like to do this, I'll have to iterate over the
relevant prefs branch(es) ahead of time (on the main thread) and copy
all
the entries to some other place that is then available to my worker
threads.
For my use case, at least, the other threads only need read access;
modifying prefs could still be limited to the main thread.
That's probably your best option, yeah. Although I will say that those
kinds
of extensible preference sets aren't great for performance or memory
usage,
so switching to some other model might be better.
Possible? Or would the overhead of locking be too crippling?
The latter, I'm afraid.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation
On two occasions I have been asked, "Pray, Mr. Babbage, if you put
into the machine wrong figures, will the right answers come out?" I am
not able rightly to apprehend the kind of confusion of ideas that
could provoke such a question.
--Charles Babbage
_______________________________________________
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
