Notes for people investigating using Android ashmem

[Mike Hommey]

Hi,

As I hear there are several people interested in Android's ashmem for
"free" cache eviction, here are a few things I learned about it in the
course of bug 686728:

- When you allocate ashmem, unless you explicitely unpin it, it will
never be purged by the kernel.
- When ashmem is purged by the kernel, it ends up being in the exact
same state as if it had just been allocated: accessible and filled
with zeros. It is important to note that this *also* includes the
state, which means if you fill it again, it won't be purged again
unless you unpin it!
- If my reading of the kernel source is correct, ashmem unpinned
ranges are purged at once: you can't end up with half purged and half
not purged. However, it is possible to unpin an ashmem by small
chunks, in which case it is possible that some chunks are purged and
others not.

Some further thoughts:

- The same effect as ashmem can be (mostly) implemented on Linux without
ashmem, by mmapping a file in /dev/shm or another tmpfs, and use
madvise(MADV_REMOVE) to purge; the main difference is that the latter
is (obviously) not automatically triggered by the kernel on low memory.
- If the memory region doesn't need to be shared across processes,
/dev/zero can be used instead in the above.
- OSX seems to have something similar to ashmem purge on anonymous
mappings, with VM_FLAGS_PURGABLE, but it seems impossible to find a
clear documentation as to what it does and when.
- Considering the above, and that the same as madvise(MADV_REMOVE) can
be achieved on Windows by decommitting and recommitting, we could have
a generic and cross platform purgeable cache handling class for things
we don't need to share across processes, where the cache eviction
would be manually triggered on non-Android non-OSX.

Cheers,

Mike

[Mike Hommey]

On Thu, Sep 15, 2011 at 11:32:29AM +0200, Mike Hommey wrote:
> Hi,
>
> As I hear there are several people interested in Android's ashmem for
> "free" cache eviction, here are a few things I learned about it in the
> course of bug 686728:
>
> - When you allocate ashmem, unless you explicitely unpin it, it will
> never be purged by the kernel.
> - When ashmem is purged by the kernel, it ends up being in the exact
> same state as if it had just been allocated: accessible and filled
> with zeros. It is important to note that this *also* includes the
> state, which means if you fill it again, it won't be purged again
> unless you unpin it!
> - If my reading of the kernel source is correct, ashmem unpinned
> ranges are purged at once: you can't end up with half purged and half
> not purged. However, it is possible to unpin an ashmem by small
> chunks, in which case it is possible that some chunks are purged and
> others not.

Also, purge happens in least recently *unpinned" region order. Which
means the only safe way to access ashmem is to pin it before use, and
unpin after. Conveniently, pinning also tells you whether the region
you're pinning was purged, so the use pattern is really pin, generate if
purged, use, unpin.

Mike

[Neil]

Mike Hommey wrote:

>On Thu, Sep 15, 2011 at 11:32:29AM +0200, Mike Hommey wrote:
>
>
>>As I hear there are several people interested in Android's ashmem for "free" cache eviction
>>

>Also, purge happens in least recently *unpinned" region order. Which means the only safe way to access ashmem is to pin it before use, and unpin after. Conveniently, pinning also tells you whether the region you're pinning was purged, so the use pattern is really pin, generate if purged, use, unpin.
>
>

Wow, this takes me back! I'm reminded of Win16's
GlobalAlloc(GMEM_DISCARDABLE, ...)

--
Warning: May contain traces of nuts.

[Jason Duell]

On 09/15/2011 02:32 AM, Mike Hommey wrote:
> - When you allocate ashmem, unless you explicitely unpin it, it will
> never be purged by the kernel.

What if process(es) using the segment die? Does that count as an unpin?

Jason

[Mike Hommey]

When the last process using the segment dies, the memory is freed.

Mike