From: Davidlohr Bueso <davidlohr@hp.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>,
Michel Lespinasse <walken@google.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Rik van Riel <riel@redhat.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
aswin@hp.com, linux-mm <linux-mm@kvack.org>,
linux-kernel@vger.kernel.org, Davidlohr Bueso <davidlohr@hp.com>
Subject: [PATCH 0/3] mm,vdso: preallocate new vmas
Date: Thu, 17 Oct 2013 17:50:35 -0700 [thread overview]
Message-ID: <1382057438-3306-1-git-send-email-davidlohr@hp.com> (raw)
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2013-10-18 0:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-18 0:50 Davidlohr Bueso [this message]
2013-10-18 0:50 ` [PATCH 1/3] mm: add mlock_future_check helper Davidlohr Bueso
2013-10-23 9:30 ` walken
2013-10-18 0:50 ` [PATCH 2/3] mm/mlock: prepare params outside critical region Davidlohr Bueso
2013-10-23 9:33 ` walken
2013-10-23 9:46 ` Vlastimil Babka
2013-10-18 0:50 ` [PATCH 3/3] vdso: preallocate new vmas Davidlohr Bueso
2013-10-18 1:17 ` Linus Torvalds
2013-10-18 5:59 ` Richard Weinberger
2013-10-18 6:05 ` [PATCH 4/3] x86/vdso: Optimize setup_additional_pages() Ingo Molnar
2013-10-21 3:52 ` Davidlohr Bueso
2013-10-21 5:27 ` Ingo Molnar
2013-10-21 3:26 ` [PATCH 3/3] vdso: preallocate new vmas Davidlohr Bueso
2013-10-23 9:53 ` walken
2013-10-25 0:55 ` Davidlohr Bueso
2013-10-22 15:48 ` [PATCH 0/3] mm,vdso: " walken
2013-10-22 16:20 ` Linus Torvalds
2013-10-22 17:04 ` Michel Lespinasse
2013-10-22 17:54 ` Andy Lutomirski
2013-10-23 10:13 ` Michel Lespinasse
2013-10-23 21:42 ` Andy Lutomirski
2013-10-23 2:46 ` Davidlohr Bueso
2013-11-05 0:39 ` Davidlohr Bueso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1382057438-3306-1-git-send-email-davidlohr@hp.com \
--to=davidlohr@hp.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=aswin@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@kernel.org \
--cc=riel@redhat.com \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--cc=walken@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox