gsvelto

5 ms·

1.
by gsvelto 4y ago
You're assuming that Firefox is eating all your commit space, but it's not, far from it, I can see it from the crash reports. You've got other applications running and they are also fighting for it, leaving large chunks unuse
2.
by gsvelto 4y ago
From the looks of it you have a minuscule page file (16MiB), that's why you're running out of commit space. I suggest setting it to auto-resize (the Windows default) which should provide a much better experience even with other ap
3.
by gsvelto 4y ago
Could you open a bug on our tracker, and point to those crash reports? I'm very interested in analyzing real-world scenarios where this happens to figure out where those committed areas are coming from. Our best guess is that they come
4.
by gsvelto 4y ago
Yes it does, we've disabled tab unloading on Linux because low-memory detection just didn't work. We will re-enabled it sometimes down the line but only to avoid swap, not crashes. The OOM killer does already a good job with this
5.
by gsvelto 4y ago
But is it? I wanted it to be tongue-in-cheek but the title is actually a rather accurate description of the contents of the article. This is a ~20 lines weird hack that we threw at the wall to see if it would stick... and it massively imp
6.
by gsvelto 4y ago
Here's the thing: they're not! The reason those users where crashing was because something, somewhere (possibly in the graphics stack) was reserving ton of space without using it. We had crashes on file with 20+ GiB of free physic
7.
by gsvelto 4y ago
I'm glad you noticed! We did indeed roll an improvement on Linux too, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1771712 In a nutshell we're directing the OOM killer towards less interesting processes withi
8.
by gsvelto 4y ago
They do and so does jemalloc in Firefox, however that lowers contention, it doesn't let you do away with synchronization. Consider this simple scenario: a thread allocates a chunk of memory from its per-thread pool, but the object is l
9.
by gsvelto 4y ago
You're confusing general purpose locks with special-purpose ones used in the memory allocator. Firefox has its own GP locks, you can find them here: https://searchfox.org/mozilla-central/search?q=&path=xpcom%2.
10.
by gsvelto 4y ago
No specific hardware support is needed to implement a lock. The atomic operations are all accessible from user-space - they are platform dependent though. The problem with locks is that they interact with scheduling and that's where th
11.
by gsvelto 4y ago
In a word: no. Efficient locks can only be implemented with significant involvement from the kernel. The best locks that can be implemented entirely in user-space will still suffer from the problems described in the article. Locks have comp
12.
by gsvelto 4y ago
If you could grab a profile of the problem with the Firefox profiler and file a bug it would be greatly appreciated. From the sounds of it it's probably an edge-case we're not aware of where Firefox performs very poorly. The probl
13.
by gsvelto 4y ago
Post author here, `__ulock_wait2` is used under the hood by `os_unfair_lock()`. I considered it but it would have required more scaffolding, especially to support all the versions of macOS we care about. We might use it in the future though
14.
by gsvelto 5y ago
Recent Linux kernels allow you to measure memory consumption from a QoS point-of-view via pressure stall information: https://www.kernel.org/doc/html/latest/accounting/psi.html This isn't the same t
15.
by gsvelto 5y ago
Unfortunately those crashes do not appear to be related to low memory scenarios. They seem to be genuine bugs in the screen reader. I think the right bug tracking them is this one: https://bugzilla.mozilla.org/show_bug.cgi?i
16.
by gsvelto 5y ago
Detecting low memory scenarios is surprisingly hard on desktop operating systems, but trivially simple on Android/iOS. Firefox for Android already made extensive use of this feature while desktop Firefox' available memory watcher
17.
by gsvelto 5y ago
Arch already uploads symbols for their Firefox builds so that's OK, it's the dependencies that are missing. Unwinding information is used to produce accurate stacks. If it's lacking our unwinder has to rely on heuristics to
18.
by gsvelto 5y ago
Only public symbols and unwinding information is extracted from Arch packages because they don't have debuginfo like other distros. It's better than nothing.
19.
by gsvelto 5y ago
That's a really tough problem to solve on Linux. We're actively working on it in order to make Firefox better behaved when memory gets tight but it's not easy. You can follow the work in these two bugs: https://bug
20.
by gsvelto 5y ago
Yes, that's one of the benefits. Firefox has a very large user-base compared to other FOSS projects so we will often spot bugs that others haven't noticed simply thanks to the sheer volume of crash reports we get.
21.
by gsvelto 5y ago
You're very welcome! If you're interested in the topic we've got a working group [1] and a very active channel on chat.mozilla.org [2]. Besides the actual stability work we've also been busy either rewriting some of this
22.
by gsvelto 5y ago
I think I started scraping symbols from Fedora 34 builds on Monday, we probably haven't looked at those crashes yet.
23.
by gsvelto 5y ago
We do gather symbol information on Windows too, but it's a lot less detailed than what we get from Linux. It also requires jumping through a lot of hoops. For example we get minimal information from Windows graphics drivers and we hav
24.
by gsvelto 6y ago
It's rasdaemon these days: https://www.setphaserstostun.org/posts/monitoring-ecc-memory...
25.
KaiOS Technologies and Mozilla partner to enable a healthy mobile internet(kaiostech.com)
11 points by gsvelto 7y ago|1 comments
26.
by gsvelto 7y ago
And also a VP
27.
by gsvelto 7y ago
A fairly large number of managers have been laid off too.