Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752574Ab3JWJxp (ORCPT ); Wed, 23 Oct 2013 05:53:45 -0400 Received: from mail-ee0-f47.google.com ([74.125.83.47]:51858 "EHLO mail-ee0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751577Ab3JWJxn (ORCPT ); Wed, 23 Oct 2013 05:53:43 -0400 Date: Wed, 23 Oct 2013 02:53:37 -0700 From: walken@google.com To: Davidlohr Bueso Cc: Andrew Morton , Linus Torvalds , Ingo Molnar , Michel Lespinasse , Peter Zijlstra , Rik van Riel , Tim Chen , aswin@hp.com, linux-mm , linux-kernel@vger.kernel.org, Russell King , Catalin Marinas , Will Deacon , Richard Kuo , Ralf Baechle , Benjamin Herrenschmidt , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , Paul Mundt , Chris Metcalf , Jeff Dike , Richard Weinberger , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" Subject: Re: [PATCH 3/3] vdso: preallocate new vmas Message-ID: <20131023095337.GC2862@localhost> References: <1382057438-3306-1-git-send-email-davidlohr@hp.com> <1382057438-3306-4-git-send-email-davidlohr@hp.com> <1382325975.2402.3.camel@buesod1.americas.hpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1382325975.2402.3.camel@buesod1.americas.hpqcorp.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2866 Lines: 64 On Sun, Oct 20, 2013 at 08:26:15PM -0700, Davidlohr Bueso wrote: > From: Davidlohr Bueso > 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 > Cc: Russell King > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Richard Kuo > Cc: Ralf Baechle > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Martin Schwidefsky > Cc: Heiko Carstens > Cc: Paul Mundt > Cc: Chris Metcalf > Cc: Jeff Dike > Cc: Richard Weinberger > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: Peter Zijlstra > --- > 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 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/