yeah i honestly don't see any smoking gun in that output, but, still, strange. don't understand why your pulseaudio is using 2.6GiB of RAM while mine is using 10MiB :/
Conversation
I wonder if all along I've had some kind of stupid kernel config option set that makes everything terrible?
1
1
2
The in-memory caching in Firefox/Chromium is also quite heavyweight on desktop Linux compared to other platforms.
On Windows, they release caches with MEM_RESET and then use MEM_RESET_UNDO to get them back when they want to use them. If there was memory pressure, it's gone.
1
On Android, ashmem has unpin/pin to do the same thing.
MADV_FREE isn't usable since you don't have a way to undo it and check if everything was preserved. You can look at the platform abstraction code and it's just stubbed out for non-Android Linux so it holds onto more memory.
2
I wonder if it makes sense to bring ashmem to mainline?
1
It is in mainline. 100% of the mandatory features for Android including Binder and ashmem are there. It's just that ashmem isn't usually enabled on non-Android platforms. Android also doesn't actually allow applications to directly use the full API via SELinux restrictions.
2
1
gears are turning in my head. i wonder if bringing ashmem to alpine makes sense
1
3
It is actually a useful, well-designed API. It's just a replacement for the legacy /dev/shm API. The unpin/pin features are quite useful too. You could easily set it up so that Chromium/Firefox would use it.
It just doesn't make sense that you can only do unpin/pin for ashmem.
2
4
why is it that every time i talk to you, i usually wind up learning at least two or more new things ♥️
1
6
Learned something myself about this:
twitter.com/DanielMicay/st
memfd is basically the same thing as ashmem without unpinning/pinning support.
Unfortunately, appears they decided that's good enough and deprecated unpinning/pinning rather than actually providing parity with it.
Quote Tweet
Replying to @ariadneconill
Unfortunately, it seems they've actually deprecated unpinning / pinning memory since Android 10 in order to replace the kernel ashmem with memfd.
I don't think there's another way to do the equivalent of Windows MEM_RESET / MEM_RESET_UNDO on Linux, unfortunately.
The Android kernels still enable ashmem but I guess the intention is to phase it out soon. The userspace API was taught to use either and implements unpinning/pinning into a no-op for memfd. Fairly sad...
Ideally Linux kernel would just get something like the Windows API though.
1