On Sun, Oct 20, 2013 at 08:26:15PM -0700, Davidlohr Bueso wrote: > From: Davidlohr Bueso <[email protected]> > Subject: [PATCH v2 3/3] vdso: preallocate new vmas > > With the exception of um and tile, architectures that use > the install_special_mapping() function, when setting up a > new vma at program startup, do so with the mmap_sem lock > held for writing. Unless there's an error, this process > ends up allocating a new vma through kmem_cache_zalloc, > and inserting it in the task's address space. > > This patch moves the vma's space allocation outside of > install_special_mapping(), and leaves the callers to do so > explicitly, without depending on mmap_sem. The same goes for > freeing: if the new vma isn't used (and thus the process fails > at some point), it's caller's responsibility to free it - > currently this is done inside install_special_mapping. > > Furthermore, uprobes behaves exactly the same and thus now the > xol_add_vma() function also preallocates the new vma. > > While the changes to x86 vdso handling have been tested on both > large and small 64-bit systems, the rest of the architectures > are totally *untested*. Note that all changes are quite similar > from architecture to architecture. > > Signed-off-by: Davidlohr Bueso <[email protected]> > Cc: Russell King <[email protected]> > Cc: Catalin Marinas <[email protected]> > Cc: Will Deacon <[email protected]> > Cc: Richard Kuo <[email protected]> > Cc: Ralf Baechle <[email protected]> > Cc: Benjamin Herrenschmidt <[email protected]> > Cc: Paul Mackerras <[email protected]> > Cc: Martin Schwidefsky <[email protected]> > Cc: Heiko Carstens <[email protected]> > Cc: Paul Mundt <[email protected]> > Cc: Chris Metcalf <[email protected]> > Cc: Jeff Dike <[email protected]> > Cc: Richard Weinberger <[email protected]> > Cc: Thomas Gleixner <[email protected]> > Cc: Ingo Molnar <[email protected]> > Cc: "H. Peter Anvin" <[email protected]> > Cc: Peter Zijlstra <[email protected]> > --- > v2: > - Simplify install_special_mapping interface (Linus Torvalds) > - Fix return for uml_setup_stubs when mem allocation fails (Richard > Weinberger)
I'm still confused as to why you're seeing any gains with this one. This code runs during exec when mm isn't shared with any other threads yet, so why does it matter how long the mmap_sem is held since nobody else can contend on it ? (well, except for accesses from /fs/proc/base.c, but I don't see why these would matter in your benchmarks either). -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
