Re: process creation time increases linearly with shmem

[Nick Piggin <nickpiggin@yahoo.com.au>]

Hugh Dickins wrote:
> On Thu, 25 Aug 2005, Linus Torvalds wrote:

>>That said, I think it's a valid optimization. Especially as the child 
>>_probably_ doesn't need it (ie there's at least some likelihood of an 
>>execve() or similar).
> 
> 
> I agree, seems a great idea to me (sulking because I was too dumb
> to get it, even when Nick and Andi first posted their patches).
> 
> It won't just save on the copying at fork time, it'll save on
> undoing it all again when the child mm is torn down for exec.
> 
> The refaulting will hurt the performance of something: let's
> just hope that something doesn't turn out to be a show-stopper.
> 

OK let's see how Ray goes, and try it when 2.6.14 opens...

> I see some flaws in the various patches posted, including Rik's.
> Here's another version - doing it inside copy_page_range, so this
> kind of vma special-casing is over in mm/ rather than kernel/.
> 

Yeah I guess that's a good idea. Patch looks pretty good.
Just a minor issue with the comment, it is not strictly
just assuming the child will exec... IMO it is worthwhile
in Ray's case even if his forked process _eventually_ ends
up touching all the shared memory pages, it is better to
avoid many ms of fork overhead.

Also, on NUMA systems this will help get page tables allocated
on the right nodes, which is not an insignificant problem for
big HPC jobs.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com