[lkml]   [2008]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [-mm] Add an owner to the mm_struct (v8)
    Paul Menage wrote:
    > On Fri, Apr 4, 2008 at 1:28 AM, Balbir Singh <> 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

     \ /
      Last update: 2008-04-04 11:31    [W:0.025 / U:0.372 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site