Messages in this thread |  | | Date | Mon, 1 Jun 2009 19:11:37 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [PATCH] TOMOYO: Add garbage collector support. (v2) |
| |
Quoting Tetsuo Handa (penguin-kernel@I-love.SAKURA.ne.jp): > Hello. > > Serge E. Hallyn wrote: > > So yes, you might be able to get more review of your patch > > if you split it up into: > > > > 1. move allocations outside of semaphore > > 2. add proper refcounting > > 3. get rid of ->is_deleted > > I'm ready to post part (1) and part (2). > But I'm not sure whether part (3) is worth to implement or not. > > If we don't use is_deleted flag, we will need two "struct list_head"s, > one is for readers and writers, the other is for GC. > > struct something { > struct { > struct list_head list; > atomic_t users; > } entry; > int data; > bool is_deleted; > } *p; > > If we remove p from the list using list_del() (or list_del_rcu()) instead of > setting p->is_deleted to true, we have to somehow remember the element pointed > by p so that that element is reachable from the GC's list. > We can't wait for p->entry.users to become 0 inside writer function (which is > called only when modifying lists). Only GC function (which is called > repeatedly) can check whether p->entry.users == 0 or not because the element > pointed by p is long-lived. We need to remember the location of the element > pointed by p .
?
Can't you just move the deleted item from the live list to some dead list, using the same ->list list_head?
> We can allocate memory when adding p to GC's list, but allocating memory at > list_del() (or list_del_rcu()) time could fail. It is not a good thing that > removing an element from the reader's list fails because of -ENOMEM. We already > have a way (i.e. is_deleted flag) to avoid -ENOMEM. > > We can add another "struct list_head" to each element which is used by GC. > But that approach consumes more memory than is_deleted flag.
?
See above.
-serge
|  |