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
next 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®