Messages in this thread | | | Date | Fri, 4 Apr 2008 01:50:15 -0700 | From | "Paul Menage" <> | Subject | Re: [-mm] Add an owner to the mm_struct (v8) |
| |
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 ...
> > 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?
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.
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).
Paul
| |