Messages in this thread | | | Date | Tue, 25 Mar 2008 17:11:39 +0530 | From | Balbir Singh <> | Subject | Re: [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
| |