Messages in this thread | | | Date | Fri, 04 Apr 2008 14:55:14 +0530 | From | Balbir Singh <> | Subject | Re: [-mm] Add an owner to the mm_struct (v8) |
| |
Paul Menage wrote: > On Fri, Apr 4, 2008 at 1:28 AM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote: >> It won't uncharge for the memory controller from the root cgroup since each page >> has the mem_cgroup information associated with it. > > Right, I realise that the memory controller is OK because of the ref counts. > >> For other controllers, >> they'll need to monitor exit() callbacks to know when the leader is dead :( (sigh). > > That sounds like a nightmare ... >
Yes, it would be, but worth the trouble. Is it really critical to move a dead cgroup leader to init_css_set in cgroup_exit()?
>> Not having the group leader optimization can introduce big overheads (consider >> thousands of tasks, with the group leader being the first one to exit). > > Can you test the overhead? >
I probably can write a program and see what the overhead looks like
> As long as we find someone to pass the mm to quickly, it shouldn't be > too bad - I think we're already optimized for that case. Generally the > group leader's first child will be the new owner, and any subsequent > times the owner exits, they're unlikely to have any children so > they'll go straight to the sibling check and pass the mm to the > parent's first child. > > Unless they all exit in strict sibling order and hence pass the mm > along the chain one by one, we should be fine. And if that exit > ordering does turn out to be common, then simply walking the child and > sibling lists in reverse order to find a victim will minimize the > amount of passing. >
Finding the next mm might not be all that bad, but doing it each time a task exits, can be an overhead, specially for large multi threaded programs. This can get severe if the new mm->owner belongs to a different cgroup, in which case we need to use callbacks as well.
If half the threads belonged to a different cgroup and the new mm->owner kept switching between cgroups, the overhead would be really high, with the callbacks and the mm->owner changing frequently.
> One other thing occurred to me - what lock protects the child and > sibling links? I don't see any documentation anywhere, but from the > code it looks as though it's tasklist_lock rather than RCU - so maybe > we should be holding that with a read_lock(), at least for the first > two parts of the search? (The full thread search is RCU-safe). >
You are right about the read_lock()
-- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL
| |