Messages in this thread |  | | | Date | Fri, 3 Jul 2009 09:50:00 -0700 | | From | Andrew Morton <> | | Subject | Re: [PATCH 1/2] Adds a read-only "procs" file similar to "tasks" that shows only unique tgids |
On Fri, 3 Jul 2009 09:11:56 -0700 Paul Menage <menage@google.com> wrote:
> Hmm, I guess we could use a combination of the IDR approach that you > suggested and the present shared-array approach: > > - when opening a tasks file: > - populate an IDR with all the pids/tgids in the cgroup > - find any existing IDR open for the cgroup in the list keyed by > namespace and filetype ("procs"/"tasks") > - replace (and free) the existing IDR or extend the list with a new one > - bump the refcount > > - when reading: > - iterate from the last reported pid/tgid > > - when closing: > - drop the refcount, and free the IDR if the count reaches 0 > > That maintains the property of preventing userspace from consuming > arbitrary amounts of memory just by holding an fd open on a large > cgroup, while also maintaining a consistency guarantee, and we get the > ordering for free as a side-effect of the IDR, with no large memory > allocations. It's not hugely different from the current solution - all > we're doing is replacing the large array in the cgroup_pidlist > structure with an IDR, and populating/reading it appropriately.
I think you're saying "for each pid N in the cgroup, set the Nth element in an IDR tree". That would work. And it automatically gives ordered traversal and dupe removal.
I don't think IDRs permit in-order traversal, whereas radix-trees do support this. Unfortunately radix-trees are presented as operating on void* data, so one would need to do some typecasting when storing BITS_PER_LONG-sized bitfields inside them.
> The downsides would be a higher fixed cost, I suspect - setting up an > IDR and populating/scanning it sounds like it has to be more expensive > than filling/reading a linear buffer. But it's probably not enough > extra overhead to worry too much about it.
Yes, I expect it'd be fairly modest. There will be far more calls to kmalloc() when using a tree, but that's the whole point..
|  |