From: "Aubrey Li" <aubreylee@gmail.com>
To: "David Howells" <dhowells@redhat.com>,
vapier.adi@gmail.com, jie.zhang@analog.com
Cc: bryan.wu@analog.com, "Andrew Morton" <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag
Date: Fri, 30 Mar 2007 18:34:15 +0800 [thread overview]
Message-ID: <6d6a94c50703300334w6b4787f3p144715de5166d7bc@mail.gmail.com> (raw)
In-Reply-To: <10785.1175247540@redhat.com>
On 3/30/07, David Howells <dhowells@redhat.com> wrote:
> Wu, Bryan <bryan.wu@analog.com> wrote:
>
> > It takes lots of time in malloc()->mmap()->do_mmap_private()->memset(). When
> > malloc a big area, memset() the area to zero makes the performance very bad.
>
> Ummm...
>
> How do you then cope with attempting to run that same application under
> MMU-mode Linux? Won't MMU mmap() give EINVAL? If so, then that'd be grounds
> for NAK'ing this patch in the form given.
>
> My theory is that NOMMU binaries should run just as well under an MMU-mode
> kernel as under a NOMMU kernel.
>
> What you're asking for is also a security risk - though obviously on NOMMU-mode
> one that's fairly irrelevant. It might even make a lot of sense there to move
> the clearance into uClibc where possible rather than doing it in the kernel.
>
> On MMU-mode kernels, the option should just be ignored.
>
> I'd also recommend you stick a 'D' on the end of 'MAP_UNINITIALIZE' or may be
> call it MAP_UNCLEARED'. But that's a minor point, but you're not telling
> mmap() to go and uninitialise the memory...
>
> Lastly, why do you actually need VM_UNINITIALIZE at all? The flag is only used
> in a place where MAP_UNINITIALIZE is still available (okay, you'll have to hand
> it down as an extra argument). That looks like a waste of a VM_xxx flag, and
> we don't have that many to spare.
>
Well, I don't understand why we have to clear the allocation memory.
I suggest we just remove the memset(addr, 0, len) operation at all.
Read the malloc manual, you'll get
--------
malloc() allocates size bytes and returns a pointer to the allocated memory.
****The memory is not cleared.****
--------
So, if not clearing the memory causes one application hang/crash,
that's the bug of that application and it need to be fixed.
The patch in my option is:
------------------------------------
diff --git a/mm/nommu.c b/mm/nommu.c
index cbbc137..fe2b6d4 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -759,10 +759,6 @@ static int do_mmap_private(struct vm_are
/* clear the last little bit */
if (ret < len)
memset(base + ret, 0, len - ret);
-
- } else {
- /* if it's an anonymous mapping, then just clear it */
- memset(base, 0, len);
}
return 0;
----------------------------------------
-Aubrey
next prev parent reply other threads:[~2007-03-30 10:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-30 3:42 Wu, Bryan
2007-03-30 3:53 ` Mike Frysinger
2007-03-30 9:39 ` David Howells
2007-03-30 10:34 ` Aubrey Li [this message]
2007-03-30 11:24 ` David Howells
2007-03-30 13:44 ` Aubrey Li
2007-03-30 14:56 ` Alan Cox
2007-03-30 14:38 ` Aubrey Li
2007-03-30 18:13 ` Alan Cox
2007-03-30 15:11 ` David Howells
2007-03-30 15:46 ` Aubrey Li
2009-10-13 7:44 ` [PATCH] NOMMU: fix malloc performance by adding uninitialized flag Mike Frysinger
2009-10-13 15:20 ` [uClinux-dev] [PATCH] NOMMU: fix malloc performance by addinguninitialized flag Robin Getz
2009-10-13 10:10 ` [PATCH] NOMMU: fix malloc performance by adding uninitialized flag David Howells
2009-10-13 11:20 ` [PATCH v2] " Mike Frysinger
2009-10-13 13:03 ` Paul Mundt
2009-10-13 16:03 ` David Howells
2009-10-13 21:31 ` [PATCH v3] " Mike Frysinger
2009-10-13 23:04 ` David McCullough
2009-10-14 0:25 ` Greg Ungerer
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=6d6a94c50703300334w6b4787f3p144715de5166d7bc@mail.gmail.com \
--to=aubreylee@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bryan.wu@analog.com \
--cc=dhowells@redhat.com \
--cc=jie.zhang@analog.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vapier.adi@gmail.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
all inboxes | Powered by JetHome®