From: Dave Hansen <dave@linux.vnet.ibm.com>
To: npiggin@suse.de
Cc: akpm@linux-foundation.org, Nishanth Aravamudan <nacc@us.ibm.com>,
linux-mm@kvack.org, kniht@us.ibm.com, andi@firstfloor.org,
abh@cray.com, joachim.deguara@amd.com
Subject: Re: [patch 14/21] x86: add hugepagesz option on 64-bit
Date: Tue, 03 Jun 2008 10:48:02 -0700 [thread overview]
Message-ID: <1212515282.8505.19.camel@nimitz.home.sr71.net> (raw)
In-Reply-To: <20080603100939.967775671@amd.local0.net>
On Tue, 2008-06-03 at 20:00 +1000, npiggin@suse.de wrote:
> +static __init int setup_hugepagesz(char *opt)
> +{
> + unsigned long ps = memparse(opt, &opt);
> + if (ps == PMD_SIZE) {
> + hugetlb_add_hstate(PMD_SHIFT - PAGE_SHIFT);
> + } else if (ps == PUD_SIZE && cpu_has_gbpages) {
> + hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
> + } else {
> + printk(KERN_ERR "hugepagesz: Unsupported page size %lu M\n",
> + ps >> 20);
> + return 0;
> + }
> + return 1;
> +}
> +__setup("hugepagesz=", setup_hugepagesz);
> +#endif
Hi Nick,
I was talking to Nish a bit about these bits. I'm worried that this
setup isn't going to be very user friendly.
First of all, it seems a bit silly to require that users spell out all
of the huge page sizes at boot. Shouldn't we allow the small sizes to
be runtime-added as well?
This also requires that users know at boot time which page sizes are
supported, and that might not be horribly feasible if you wanted to have
a common setup among a bunch of different machines, or if the supported
sizes can change with things as insignificant as firmware revisions
(they can on ppc).
So, here's what I propose. At boot, the architecture calls
hugetlb_add_hstate() for every hardware-supported huge page size. This,
of course, gets enumerated in Nish's new sysfs interface.
Then, give the boot-time large page reservations either to hugepages= or
a new boot option. But, instead of doing it in number of hpages, do it
in sizes like hugepages=10G. Bootmem-alloc that area, and make it
available to the first hugetlbfs users that come along, regardless of
their hpage size. Do whatever is simplest here when breaking down the
large area.
I *think* this could all be done on top of what you have here.
-- Dave
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-06-03 17:48 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-03 9:59 [patch 00/21] hugetlb multi size, giant hugetlb support, etc npiggin
2008-06-03 9:59 ` [patch 01/21] hugetlb: factor out prep_new_huge_page npiggin
2008-06-03 9:59 ` [patch 02/21] hugetlb: modular state npiggin
2008-06-03 10:58 ` [patch 02/21] hugetlb: modular state (take 2) Nick Piggin
2008-06-03 9:59 ` [patch 03/21] hugetlb: multiple hstates npiggin
2008-06-03 10:00 ` [patch 04/21] hugetlbfs: per mount hstates npiggin
2008-06-03 10:00 ` [patch 05/21] hugetlb: new sysfs interface npiggin
2008-06-03 10:00 ` [patch 06/21] hugetlb: abstract numa round robin selection npiggin
2008-06-03 10:00 ` [patch 07/21] mm: introduce non panic alloc_bootmem npiggin
2008-06-03 10:00 ` [patch 08/21] mm: export prep_compound_page to mm npiggin
2008-06-03 10:00 ` [patch 09/21] hugetlb: support larger than MAX_ORDER npiggin
2008-06-03 10:00 ` [patch 10/21] hugetlb: support boot allocate different sizes npiggin
2008-06-03 10:00 ` [patch 11/21] hugetlb: printk cleanup npiggin
2008-06-03 10:00 ` [patch 12/21] hugetlb: introduce pud_huge npiggin
2008-06-03 10:00 ` [patch 13/21] x86: support GB hugepages on 64-bit npiggin
2008-06-03 10:00 ` [patch 14/21] x86: add hugepagesz option " npiggin
2008-06-03 17:48 ` Dave Hansen [this message]
2008-06-03 18:24 ` Andi Kleen
2008-06-03 18:59 ` Dave Hansen
2008-06-03 20:57 ` Andi Kleen
2008-06-03 21:27 ` Dave Hansen
2008-06-04 0:06 ` Andi Kleen
2008-06-04 1:04 ` Nick Piggin
2008-06-04 16:01 ` Dave Hansen
2008-06-06 16:09 ` Dave Hansen
2008-06-05 23:15 ` Nishanth Aravamudan
2008-06-06 0:29 ` Andi Kleen
2008-06-04 1:10 ` Nick Piggin
2008-06-05 23:12 ` Nishanth Aravamudan
2008-06-05 23:23 ` Nishanth Aravamudan
2008-06-03 19:00 ` Dave Hansen
2008-06-03 10:00 ` [patch 15/21] hugetlb: override default huge page size npiggin
2008-06-03 10:00 ` [patch 16/21] hugetlb: allow arch overried hugepage allocation npiggin
2008-06-03 10:00 ` [patch 17/21] powerpc: function to allocate gigantic hugepages npiggin
2008-06-03 10:00 ` [patch 18/21] powerpc: scan device tree for gigantic pages npiggin
2008-06-03 10:00 ` [patch 19/21] powerpc: define support for 16G hugepages npiggin
2008-06-03 10:00 ` [patch 20/21] fs: check for statfs overflow npiggin
2008-06-03 10:00 ` [patch 21/21] powerpc: support multiple hugepage sizes npiggin
2008-06-03 10:29 ` [patch 1/1] x86: get_user_pages_lockless support 1GB hugepages Nick Piggin
2008-06-03 10:57 ` [patch 00/21] hugetlb multi size, giant hugetlb support, etc Nick Piggin
2008-06-06 17:12 ` Andy Whitcroft
2008-06-04 8:29 ` Andrew Morton
2008-06-04 9:35 ` Nick Piggin
2008-06-04 9:46 ` Andrew Morton
2008-06-04 11:04 ` Nick Piggin
2008-06-04 11:33 ` Nick Piggin
2008-06-04 11:57 ` Andi Kleen
2008-06-04 18:39 ` Andrew Morton
2008-06-04 11:29 [patch 00/21] hugetlb patches resend npiggin
2008-06-04 11:29 ` [patch 14/21] x86: add hugepagesz option on 64-bit npiggin
2008-06-04 17:51 ` Randy Dunlap
2008-06-05 2:01 ` Nick Piggin
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=1212515282.8505.19.camel@nimitz.home.sr71.net \
--to=dave@linux.vnet.ibm.com \
--cc=abh@cray.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=joachim.deguara@amd.com \
--cc=kniht@us.ibm.com \
--cc=linux-mm@kvack.org \
--cc=nacc@us.ibm.com \
--cc=npiggin@suse.de \
/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