mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Mike Frysinger" <vapier.adi@gmail.com>
To: "David Howells" <dhowells@redhat.com>,
	"Greg Ungerer" <gerg@snapgear.com>,
	"David McCullough" <David_Mccullough@securecomputing.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"Bryan Wu" <Bryan.Wu@analog.com>,
	"Bernd Schmidt" <bernds_cb1@t-online.de>,
	"Robin Getz" <rgetz@blackfin.uclinux.org>
Subject: nommu: handling anonymous mmap clearing in userspace rather than kernel
Date: Tue, 1 Apr 2008 17:34:00 -0400	[thread overview]
Message-ID: <8bd0f97a0804011434r4869fbe8t89ade12c04c97f2@mail.gmail.com> (raw)

the problem: doing malloc() in userspace on no-mmu systems can take up
an inordinate amount of time merely due to kernel forcing anonymously
mapped memory to zero.  this is because the only way to implement
userspace malloc() on no-mmu systems is via mmap(MAP_ANONYMOUS), and
the kernel has an explicit memset() in mm/nommu.c:do_mmap_private()
when MAP_ANONYMOUS is in the mmap flags.  however, POSIX states that
memory returned from malloc() may be uninitialized, so this zeroing is
not wanted in that case.

the desire: be able to do a mmap(MAP_ANONYMOUS) to grab a chunk of
memory without the memset() call.  this may bring up other arguments
such as information leakage between kernels/processes, but on an
embedded no-mmu system, people are very willing to sacrifice that for
the very measurable performance gain.

a workaround: introduce a new no-mmu-only mmap flag MAP_UNINITIALIZE
to signal to the kernel that it should skip the memset().  this way,
userspace malloc() can do mmap(MAP_ANONYMOUS|MAP_UNINITIALIZE) to get
large chunks of memory without affecting any other anonymous mmap()
call.

another idea: move the memset() from the kernel to the system C
library.  make the kernel memset() controllable via a
no-mmu/embedded-only Kconfig option (with the default being retained:
the memset is called).  now the C library can easily control the
zero-ing of memory as required by POSIX, and you spend less time in
kernel space.  there are many places where the kernel<->user ABI is
not POSIX compliant and instead relies on the C library to provide the
little bit of POSIX glue, so this isnt a big deal.
-mike

             reply	other threads:[~2008-04-01 21:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-01 21:34 Mike Frysinger [this message]
2008-04-02 14:20 ` David Howells
2008-04-02 14:47   ` Mike Frysinger
2008-04-02 15:03     ` Bernd Schmidt
2008-04-02 15:07       ` Mike Frysinger
2008-04-03 11:06         ` Bernd Schmidt
2008-04-03 14:46           ` Mike Frysinger
2008-04-03 13:14         ` David Howells

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=8bd0f97a0804011434r4869fbe8t89ade12c04c97f2@mail.gmail.com \
    --to=vapier.adi@gmail.com \
    --cc=Bryan.Wu@analog.com \
    --cc=David_Mccullough@securecomputing.com \
    --cc=bernds_cb1@t-online.de \
    --cc=dhowells@redhat.com \
    --cc=gerg@snapgear.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgetz@blackfin.uclinux.org \
    /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

all inboxes | Powered by JetHome®