From: David Howells <dhowells@redhat.com>
To: Andrew Morton <akpm@osdl.org>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Permit inode & dentry hash tables to be allocated > MAX_ORDER size
Date: Fri, 11 Jun 2004 12:12:30 +0100 [thread overview]
Message-ID: <1056.1086952350@redhat.com> (raw)
In-Reply-To: <20040611034809.41dc9205.akpm@osdl.org>
> > Here's a patch to allocate memory for big system hash tables with the bootmem
> > allocator rather than with main page allocator.
>
> umm, why?
Three reasons:
(1) So that the size can be bigger than MAX_ORDER. IBM have done some testing
on their big PPC64 systems (64GB of RAM) with linux-2.4 and found that
they get better performance if the sizes of the inode cache hash, dentry
cache hash, buffer head hash and page cache hash are increased beyond
MAX_ORDER (order 11).
Now the main allocator can't allocate anything larger than MAX_ORDER, but
the bootmem allocator can.
In 2.6 it appears that only the inode and dentry hashes remain of those
four, but there are other hash tables that could use this service.
(2) Changing MAX_ORDER appears to have a number of effects beyond just
limiting the maximum size that can be allocated in one go.
(3) Should someone want a hash table in which each bucket isn't a power of two
in size, memory will be wasted as the chunk of memory allocated will be a
power of two in size (to hold a power of two number of buckets).
On the other hand, using the bootmem allocator means the allocation will
only take up sufficient pages to hold it, rather than the next power of
two up.
Admittedly, this point doesn't apply to the dentry and inode hashes, but
it might to another hash table that might want to use this service.
David
next prev parent reply other threads:[~2004-06-11 11:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-11 10:44 [PATCH] Permit inode & dentry hash tables to be allocated > MAX_ORDER size David Howells
2004-06-11 10:48 ` Andrew Morton
2004-06-11 11:12 ` David Howells [this message]
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
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=1056.1086952350@redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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