what does /proc/8766/maps look like?
Conversation
Though honestly I have very little incentive to debug pulseaudio right now, seeing as I'll be switching to PipeWire as soon as I can make snd-dice.ko not suck.
2
5
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
It doesn't actually make sense that unpin / pin is specific to ashmem rather than being something available for normal anonymous memory too.
ashmem is primarily just a better /dev/shm API with anonymous mappings which go away when last fd is gone rather than being leak prone.


