[Devel] Re: [PATCH 1/3] Adds a read-only "procs" file similar to "tasks" that shows only unique tgids
Benjamin Blum
bblum at google.com
Tue Jul 14 14:26:16 PDT 2009
On Tue, Jul 14, 2009 at 11:34 AM, Dave Hansen<dave at linux.vnet.ibm.com> wrote:
> On Fri, 2009-07-10 at 16:01 -0700, Ben Blum wrote:
>> +struct cgroup_pidlist {
>> + /* protects the other fields */
>> + struct rw_semaphore mutex;
>> + /* array of xids */
>> + pid_t *list;
>> + /* how many elements the above list has */
>> + int length;
>> + /* how many files are using the current array */
>> + int use_count;
>> +};
>
> I think a slightly nicer way of doing this would be to use a structure
> like this:
>
> #define NR_PIDS (PAGE_SIZE-sizeof(struct list_head))
> struct pid_list {
> struct list_head list;
> pid_t pids[NR_PIDS];
> };
>
> That way, you can always kmalloc(sizeof(pid_list)), it fits nicely in
> PAGE_SIZE, and you can chain them together.
>
> Or, you could always just use one of the other flexible structures in
> the kernel like a radix_tree.
>
> -- Dave
This method looks to be a compromise between Andrew's proposed
generalized solution ( http://lkml.org/lkml/2009/7/2/518 ) and the
current quick-fix. The problem with it is that it'll require a layer
between whoever's using the array and managing the list structs (for
the case where we need to chain multiple blocks together), and if
we're going to put forth enough effort for that, we may as well go
ahead and write up a generalized kernel-wide library to fix this size
problem globally.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list