On Wed, Apr 02, 2008 at 02:56:25PM -0700, Christoph Lameter wrote: > I am a bit surprised that brk performance is that important. There may be
I think it's not brk but fork that is being slowed down, did you oprofile? AIM forks a lot... The write side fast path generating the overscheduling I guess is when the new vmas are created for the child and queued in the parent anon-vma in O(1), so immediate, even preempt-rt would be ok with it spinning and not scheduling, it's just a list_add (much faster than schedule() indeed). Every time there's a collision when multiple child forks simultaneously and they all try to queue in the same anon-vma, things will slowdown. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
