Re: [PATCH v3] mm: per-thread vma caching

2014-02-27 Thread Davidlohr Bueso
On Wed, 2014-02-26 at 22:47 -0800, Michel Lespinasse wrote: > Agree with Linus; this is starting to look pretty good. > > I still have nits though :) > > On Wed, Feb 26, 2014 at 4:07 PM, Davidlohr Bueso wrote: > > @@ -0,0 +1,45 @@ > > +#ifndef __LINUX_VMACACHE_H > > +#define __LINUX_VMACACHE_H >

Re: [PATCH v3] mm: per-thread vma caching

2014-02-26 Thread Michel Lespinasse
Agree with Linus; this is starting to look pretty good. I still have nits though :) On Wed, Feb 26, 2014 at 4:07 PM, Davidlohr Bueso wrote: > @@ -0,0 +1,45 @@ > +#ifndef __LINUX_VMACACHE_H > +#define __LINUX_VMACACHE_H > + > +#include > + > +#ifdef CONFIG_MMU > +#define VMACACHE_BITS 2 > +#else

Re: [PATCH v3] mm: per-thread vma caching

2014-02-26 Thread Linus Torvalds
Ok, I think this is in a mergable form. I wonder what the heck that insane tlb flush is in kgdb_flush_swbreak_addr(), but it predates this, and while it makes no sense to me, the patch makes it no worse. And I can't find it in myself to care. Does anybody see anything odd? If not, add an acked-by

[PATCH v3] mm: per-thread vma caching

2014-02-26 Thread Davidlohr Bueso
From: Davidlohr Bueso This patch is a continuation of efforts trying to optimize find_vma(), avoiding potentially expensive rbtree walks to locate a vma upon faults. The original approach (https://lkml.org/lkml/2013/11/1/410), where the largest vma was also cached, ended up being too specific and