Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753491Ab3JRAuw (ORCPT ); Thu, 17 Oct 2013 20:50:52 -0400 Received: from g1t0026.austin.hp.com ([15.216.28.33]:40893 "EHLO g1t0026.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753149Ab3JRAuv (ORCPT ); Thu, 17 Oct 2013 20:50:51 -0400 From: Davidlohr Bueso To: Andrew Morton , Linus Torvalds Cc: Ingo Molnar , Michel Lespinasse , Peter Zijlstra , Rik van Riel , Tim Chen , aswin@hp.com, linux-mm , linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: [PATCH 0/3] mm,vdso: preallocate new vmas Date: Thu, 17 Oct 2013 17:50:35 -0700 Message-Id: <1382057438-3306-1-git-send-email-davidlohr@hp.com> X-Mailer: git-send-email 1.8.1.4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2577 Lines: 59 Linus recently pointed out[1] some of the amount of unnecessary work being done with the mmap_sem held. This patchset is a very initial approach on reducing some of the contention on this lock, and moving work outside of the critical region. Patch 1 adds a simple helper function. Patch 2 moves out some trivial setup logic in mlock related calls. Patch 3 allows managing new vmas without requiring the mmap_sem for vdsos. While it's true that there are many other scenarios where this can be done, few are actually as straightforward as this in the sense that we *always* end up allocating memory anyways, so there's really no tradeoffs. For this reason I wanted to get this patch out in the open. There are a few points to consider when preallocating vmas at the start of system calls, such as how many new vmas (ie: callers of split_vma can end up calling twice, depending on the mm state at that point) or the probability that we end up merging the vma instead of having to create a new one, like the case of brk or copy_vma. In both cases the overhead of creating and freeing memory at every syscall's invocation might outweigh what we gain in not holding the sem. [1] https://lkml.org/lkml/2013/10/9/665 Thanks! Davidlohr Bueso (3): mm: add mlock_future_check helper mm/mlock: prepare params outside critical region vdso: preallocate new vmas arch/arm/kernel/process.c | 22 +++++++++---- arch/arm64/kernel/vdso.c | 21 ++++++++++--- arch/hexagon/kernel/vdso.c | 16 +++++++--- arch/mips/kernel/vdso.c | 10 +++++- arch/powerpc/kernel/vdso.c | 11 +++++-- arch/s390/kernel/vdso.c | 19 +++++++++--- arch/sh/kernel/vsyscall/vsyscall.c | 11 ++++++- arch/tile/kernel/vdso.c | 13 ++++++-- arch/um/kernel/skas/mmu.c | 16 +++++++--- arch/unicore32/kernel/process.c | 17 +++++++--- arch/x86/um/vdso/vma.c | 18 ++++++++--- arch/x86/vdso/vdso32-setup.c | 16 +++++++++- arch/x86/vdso/vma.c | 10 +++++- include/linux/mm.h | 3 +- kernel/events/uprobes.c | 14 +++++++-- mm/mlock.c | 18 ++++++----- mm/mmap.c | 63 ++++++++++++++++++-------------------- 17 files changed, 213 insertions(+), 85 deletions(-) -- 1.8.1.4 -- 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/