lkml.org 
[lkml]   [2008]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][-mm] Memory controller add mm->owner
    Paul Menage wrote:
    > On Mon, Mar 24, 2008 at 10:33 AM, Balbir Singh
    > <balbir@linux.vnet.ibm.com> wrote:
    >> > OK, so we don't need to handle this for NPTL apps - but for anything
    >> > still using LinuxThreads or manually constructed clone() calls that
    >> > use CLONE_VM without CLONE_PID, this could still be an issue.
    >>
    >> CLONE_PID?? Do you mean CLONE_THREAD?
    >
    > Yes, sorry - CLONE_THREAD.
    >
    >> For the case you mentioned, mm->owner is a moving target and we don't want to
    >> spend time finding the successor, that can be expensive when threads start
    >> exiting one-by-one quickly and when the number of threads are high. I wonder if
    >> there is an efficient way to find mm->owner in that case.
    >>
    >
    > But:
    >
    > - running a high-threadcount LinuxThreads process is by definition
    > inefficient and expensive (hence the move to NPTL)
    >
    > - any potential performance hit is only paid at exit time
    >
    > - in the normal case, any of your children or one of your siblings
    > will be a suitable alternate owner
    >
    > - in the worst case, it's not going to be worse than doing a
    > for_each_thread() loop
    >
    > so I don't think this would be a major problem
    >

    I've been looking at zap_threads, I suspect we'll end up implementing a similar
    loop, which makes me very uncomfortable. Adding code for the least possible
    scenario. It will not get invoked for CLONE_THREAD, but will get invoked for the
    case when CLONE_VM is set without CLONE_THREAD.

    I'll try and experiment a bit more and see what I come up with


    --
    Warm Regards,
    Balbir Singh
    Linux Technology Center
    IBM, ISTL


    \
     
     \ /
      Last update: 2008-03-25 12:47    [W:3.194 / U:0.548 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site