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.

Ariadne Conill

@ariadneconill

Jun 26, 2021

Replying to

@marcan42

and

@yyolk

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 :/

Replying to

and

I wonder if all along I've had some kind of stupid kernel config option set that makes everything terrible?

Replying to

and

dunno. thunderbird made some amount of sense, all of the RSS data is probably cached stuff, sqlite databases, etc

Replying to

and

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.

Replying to

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.

Replying to

and

I wonder if it makes sense to bring ashmem to mainline?

Replying to

and

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.

4:53 AM · Jun 26, 2021Twitter Web App

Replying to

and

gears are turning in my head. i wonder if bringing ashmem to alpine makes sense

Replying to

and

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.

Show replies

Replying to

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.