Re: [Patch 2/3] fast VMA recycling

[Arjan van de Ven <arjan@linux.intel.com>]

On Thu, 2006-02-23 at 11:05 +0100, Andi Kleen wrote:
> On Thursday 23 February 2006 10:48, Arjan van de Ven wrote:
> > On Thu, 2006-02-23 at 10:42 +0100, Andi Kleen wrote:
> > > On Thursday 23 February 2006 10:30, Arjan van de Ven wrote:
> > > > This patch adds a per task-struct cache of a free vma. 
> > > > 
> > > > In normal operation, it is a really common action during userspace mmap 
> > > > or malloc to first allocate a vma, and then find out that it can be merged,
> > > > and thus free it again. In fact this is the case roughly 95% of the time.
> > > > 
> > > > In addition, this patch allows code to "prepopulate" the cache, and
> > > > this is done as example for the x86_64 mmap codepath. The advantage of this
> > > > prepopulation is that the memory allocation (which is a sleeping operation
> > > > due to the GFP_KERNEL flag, potentially causing either a direct sleep or a 
> > > > voluntary preempt sleep) will happen before the mmap_sem is taken, and thus 
> > > > reduces lock hold time (and thus the contention potential)
> > > 
> > > The slab fast path doesn't sleep. 
> > 
> > it does via might_sleep()
> 
> Hmm? That shouldn't sleep.

see voluntary preempt.


> If it takes any time in a real workload then it should move into DEBUG_KERNEL
> too. But I doubt it. Something with your analysis is wrong.

well I'm seeing contention; and this is one of the things that can be
moved out of the lock easily, and especially given the high recycle rate
of these things... looks worth it to me.



> P.S.: Your email address bounces.

sorry about that; made a typo when trying to figure out how to set up
non-corrupting patches lkml

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/