Messages in this thread | | | Date | Wed, 26 Mar 2008 15:59:38 +0530 | From | Balbir Singh <> | Subject | Re: [RFC][-mm] Memory controller add mm->owner |
| |
Balbir Singh wrote: > 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 >>
This will have to be the common case, since you never know what combination of clone calls did CLONE_VM and what did CLONE_THREAD. At exit time, we need to pay a for_each_process() overhead. Although very unlikely, an application can call pthread_* functions (NPTL) and then do a clone with CLONE_VM, thus forcing threads in a thread group and another process to share the mm_struct. This makes mm->owner struct approach hard to implement.
>> 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
I am yet to benchmark the cost of doing for_each_process() on every exit. I suspect, we'll see a big drop in performance. I am not sure anymore if mm->owner is worth the overhead.
-- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL
| |