From: Linus Torvalds <torvalds@osdl.org>
To: Andrew Morton <akpm@osdl.org>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
dhowells@redhat.com, linux-kernel@vger.kernel.org,
apw@shadowen.org
Subject: Re: [PATCH] Permit inode & dentry hash tables to be allocated > MAX_ORDER size
Date: Sun, 13 Jun 2004 09:09:12 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0406130905410.2969@evo.osdl.org> (raw)
In-Reply-To: <20040611161920.0a40e49d.akpm@osdl.org>
On Fri, 11 Jun 2004, Andrew Morton wrote:
>
> Confused. Why do we have that test in there at all? We should just toss
> the pages one at a time into the buddy list and let the normal coalescing
> work it out. That way we'd end up with a single 16MB "page" followed by N
> 256MB "pages".
Doesn't work that way. We use the base of the memory area as the "zero
point", and while the buddy allocator itself shouldn't really care where
that zero-point is, anybody who expects physical alignment would be really
upset if it doesn't get it.
So the base address has to be as aligned as anybody could ever want. And
"anybody" wants quite a bit of alignment. Largepages usually want
alignment guarantees, and on most architectures that means a minimum
_physical_ address alignment of at least a few megabytes.
So the rule really should be: make sure that the buddy system base address
is maximally aligned, and if your memory doesn't actually _start_ at that
alignment point, just add the pages and let the buddy allocator build up
all the bitmaps etc for you.
Linus
next prev parent reply other threads:[~2004-06-13 16:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-11 10:44 David Howells
2004-06-11 10:48 ` Andrew Morton
2004-06-11 11:12 ` David Howells
2004-06-11 22:04 ` Andrew Morton
2004-06-11 23:03 ` Martin J. Bligh
2004-06-11 23:19 ` Andrew Morton
2004-06-11 23:18 ` Martin J. Bligh
2004-06-11 23:30 ` Andrew Morton
2004-06-12 12:45 ` Andy Whitcroft
2004-06-13 16:09 ` Linus Torvalds [this message]
2004-06-11 14:21 ` [PATCH] Permit inode & dentry hash tables to be allocated > MAX_ORDER size [#2] David Howells
2004-06-11 22:01 ` Andrew Morton
2004-06-14 10:47 ` [PATCH] Permit inode & dentry hash tables to be allocated > MAX_ORDER size [try #3] David Howells
2004-06-14 11:04 ` Andrew Morton
2004-06-14 11:41 ` David Howells
[not found] <263jX-5RZ-19@gated-at.bofh.it>
[not found] ` <262nZ-56Z-5@gated-at.bofh.it>
[not found] ` <263jX-5RZ-17@gated-at.bofh.it>
2004-06-12 0:21 ` [PATCH] Permit inode & dentry hash tables to be allocated > MAX_ORDER size Andi Kleen
2004-06-12 6:00 ` Martin J. Bligh
2004-06-12 7:36 ` Dave Hansen
2004-06-12 13:11 ` Andi Kleen
2004-06-12 15:00 ` Martin J. Bligh
2004-06-15 16:40 ` Dave Hansen
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=Pine.LNX.4.58.0406130905410.2969@evo.osdl.org \
--to=torvalds@osdl.org \
--cc=akpm@osdl.org \
--cc=apw@shadowen.org \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.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®