From: Mike Travis <travis@sgi.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andi Kleen <andi@firstfloor.org>,
Cyrill Gorcunov <gorcunov@gmail.com>,
"H. Peter Anvin" <hpa@zytor.com>,
LKML <linux-kernel@vger.kernel.org>,
Yinghai Lu <yhlu.kernel@gmail.com>,
Eric Dumazet <dada1@cosmosbay.com>
Subject: Re: bootmem allocator
Date: Tue, 08 Apr 2008 23:00:28 -0700 [thread overview]
Message-ID: <47FC5B7C.3020504@sgi.com> (raw)
In-Reply-To: <20080408080446.GA12308@elte.hu>
Ingo Molnar wrote:
> * Andi Kleen <andi@firstfloor.org> wrote:
>
>>> hm, bootmem allocator is supposed to clear memory. We have a couple
>>> of places that rely on that.
>> I was actually considering to change that for the GB pages hugetlbfs
>> patchkit, because memset for 1G is a little slow and not needed (will
>> be cleared later anyways) and it might be a problem for very large
>> systems with a lot of such pages at boot.
>
> changing the default behavior of bootmem alloc to be non-clearing is a
> really bad idea that will only cause unrobustness. The proper approach
> is to add an _opt-in_ API that does not clear memory
> (bootmem_alloc_dontclear() or whatever), available to callers that know
> it for sure that they dont need the clearing.
Yes, changing the default of bootmem_alloc is a bad idea. I just changed
a bunch of static arrays to bootmem alloc's and it was pointed out early
that not only does bootmem_alloc clear memory, but also panics if it's not
available.
> Also take into account that alloc_bootmem_low() :
> - calls panic() if not enough memory
> - already clears allocated memory
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
A specialized call to bootmem_alloc probably needs it's own API... ;-)
Thanks,
Mike
next prev parent reply other threads:[~2008-04-09 6:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-07 18:56 bootmem allocator Cyrill Gorcunov
2008-04-07 19:09 ` Ingo Molnar
2008-04-07 19:44 ` Andi Kleen
2008-04-07 21:45 ` Yinghai Lu
2008-04-08 4:14 ` Cyrill Gorcunov
2008-04-08 4:33 ` H. Peter Anvin
2008-04-08 5:50 ` Cyrill Gorcunov
2008-04-08 16:18 ` Cyrill Gorcunov
2008-04-08 8:04 ` Ingo Molnar
2008-04-08 8:12 ` Andi Kleen
2008-04-08 13:57 ` Cyrill Gorcunov
2008-04-08 17:34 ` Cyrill Gorcunov
2008-04-08 17:44 ` H. Peter Anvin
2008-04-09 6:00 ` Mike Travis [this message]
2008-04-09 6:08 ` Andi Kleen
2008-04-09 6:55 ` Mike Travis
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=47FC5B7C.3020504@sgi.com \
--to=travis@sgi.com \
--cc=andi@firstfloor.org \
--cc=dada1@cosmosbay.com \
--cc=gorcunov@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=yhlu.kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.