Advertisement
Free copy of The Founder's Checklist and The Founders Pitch Deck Template from M L Bittle - New York; Advisor/Coach.
| |||||||||||||
ashmemashmemPosted Dec 21, 2011 3:05 UTC (Wed) by neilbrown (subscriber, #359)In reply to: ashmem by swetland Parent article: Bringing Android closer to the mainline
I haven't looked at ashmem so maybe it is simple and elegant and doesn't need improving.
However the use-case you describe sounds like tmpfs with "unlink-on-last-close" which is a semantic that NFS already imposes on its "silly-delete" files (where the file is unlinked on the client but still open, so must still have a name on the server) so there is some precedent for it.
Would an "unlink-on-last-close" mount option for tmpfs fit your need? It might be a generally useful thing to have.
(Log in to post comments)
ashmem Posted Dec 21, 2011 4:17 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Tmpfs also needs to enforce this option for ALL files and provide per-app quotas so that one app won't be able to eat all the space.
Besides, tmpfs footprint should be taken into account during OOM killer run.
ashmem Posted Dec 21, 2011 4:41 UTC (Wed) by cmccabe (subscriber, #60281) [Link]
> Tmpfs also needs to enforce this option for ALL files and
> provide per-app quotas so that one app won't be able to eat all the space.
Android creates a new user for each application, and runs the application as that user. So traditional per-user disk quotas should be usable, at least in theory.
> Besides, tmpfs footprint should be taken into account during
With cgroups and the userspace OOM killer framework, you can implement whatever policy you like.
ashmem Posted Dec 22, 2011 13:02 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Different users must be able to share the shared memory segment, so simple mapping doesn't work. Passing file descriptors using sockets might work, but it's ugly.
ashmem Posted Dec 22, 2011 18:35 UTC (Thu) by cmccabe (subscriber, #60281) [Link]
I think we're going to have to agree to disagree. I think passing file descriptors via sockets is elegant.
ashmem Posted May 24, 2012 8:20 UTC (Thu) by niemshchanchani (guest, #84564) [Link]
i'm trying to share memory between android and chrooted ubuntu, I know I can mount bind /dev/ashmem to the ubuntu side , and i have tried out sockets between android and ubuntu and it works . Now the question is how do i pass the fd from android to ubuntu side?
will simply passing the the fd and then mmaping work? ( i think not, but haven't tried it )
or will i need to extend something in ashmem driver ( user / kernel side) to do that? If someone has already done / knows something abt this can you give me a starting point?
ashmem Posted Dec 21, 2011 9:51 UTC (Wed) by josh (subscriber, #17465) [Link]
Linux already supports anonymous shared memory; you can call mmap with MAP_SHARED|MAP_ANONYMOUS to get an anonymous shared region. Child processes will inherit that region. The only difference: you can't get a file descriptor for the region, and thus you can't pass it around like a file descriptor, such as through a pipe. If ashmem works like a natural extension of that, allowing the association of a file descriptor with the mapping to allow passing it around, then it seems like a very reasonable addition.
In theory, a trusted process could serve the same function in userspace, by using the new cross-memory attach (CMA) mechanism. Processes could ask the trusted process to create a new piece of anonymous memory for them to use, and multiple processes could attach to that memory. (The permission issues would prove difficult to deal with, but not impossible; the trusted process would need to manage a set of cooperating processes with various credentials.) However, I think it makes sense to handle this in a much more natural way through the kernel, by associating a file descriptor with anonymous shared memory.
ashmem Posted Dec 21, 2011 12:37 UTC (Wed) by swetland (subscriber, #63414) [Link]
Yup -- that was the main limitation (not being able to get an fd to pass to another process for mapping) that ashmem was working around.
It also (though this feature came later) has functionality which allows a process to indicate ranges of pages which are not needed and may be reclaimed by the kernel in the event of a low memory situation. The idea being that using this to mark caches, etc, gives the kernel the ability to reclaim some pages as an alternative to invoking the low memory killer to obtain more memory in a pinch.
ashmem Posted Jan 1, 2012 16:16 UTC (Sun) by kleptog (subscriber, #1183) [Link]
SysV shared memory already has this. Simply set the "delete" flag on the segment as soon as it's created and as soon and the last program detaches it it's automatically deleted.
|
|||||||||||||