Conversation

Replying to

@ariadneconill

and

Replying to

and

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.

Replying to

and

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.

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.

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

Replying to

You should be able to just do that with regular anonymous memory. Android avoids implementing things downstream now though. They got all the mandatory kernel changes upstream and only have optional ones downstream. Many of those are quite useful though, like naming anon VMAs.

Replying to

So /proc/PID/maps output on Android is a lot more useful because it's possible for everything making anonymous mappings to label the mappings. It's used by OS tooling to figure out what's using memory. It also cleverly uses page APIs to divide up the blame for shared memory.

Show replies

Replying to

and

why is it that every time i talk to you, i usually wind up learning at least two or more new things ♥️

Replying to

and

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

Daniel Micay

@DanielMicay

Jun 26, 2021

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.

Show replies