Re: [RFC][-mm] Memory controller add mm->owner

[Balbir Singh]

Paul Menage wrote:
> On Mon, Mar 24, 2008 at 10:33 AM, Balbir Singh
> <balbir@xxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/