From: David Gibson <dwg@au1.ibm.com>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linux-ppc list <linuxppc-dev@ozlabs.org>
Subject: Re: using different format for hugetlbfs
Date: Wed, 9 Dec 2009 13:00:53 +1100 [thread overview]
Message-ID: <20091209020053.GC5467@yookeroo> (raw)
In-Reply-To: <82922100-59CF-466B-98E1-79711700AF19@kernel.crashing.org>
On Tue, Dec 08, 2009 at 09:44:55AM -0600, Kumar Gala wrote:
>
> On Dec 7, 2009, at 8:28 PM, David Gibson wrote:
>
> >On Mon, Dec 07, 2009 at 12:04:37PM +1100, Benjamin Herrenschmidt
> >wrote:
> >>
> >>>
> >>>Even than, does that preclude the format I suggested? I'm assuming
> >>>that pgd_t/pud_t/pmd_t are always a double word so the low order 4-
> >>>bits should be 0 (on 64-bit),
> >
> >Double word alignment only gives us 3 low bits.
> >
> >>so using the lsb as the flag between
> >>>hugetlb and normal pointer should still work.
> >>
> >>Might do, depends if David has enough bits ... David ?
> >
> >Well, the flag can go at the bottom, but that will mean grabbing more
> >bits at the bottom. At the moment to cover all the page table sizes
> >that are wanted on the various setups we have, I need 5 bits, this
> >would push it to 6. At present, I just force up the minimum alignment
> >of any page directory (even if it's natural alignment is smaller) so
> >as to make sure I have those bits. That's pretty easy to adjust, but
> >pushing it up too high will start wasting memory, of course.
> >
> >If we move to a variable sized encoding, as Ben and I have discussed
> >on a couple of occasions, I think we could do this though.
>
> I don't understand. It seems like only the flag bit of normal
> pointer vs hugetlb is the only thing that we need to distinguish.
> Once we've done that all the other bits are free to use as we see
> fit. So the less significant bit can be used for that purpose and
> the size encoding, etc we are free to do what we want with.
Well, yes, but the huge page directory pointers are still pointers, so
this is one extra bit at the bottom which counts against our minimum
alignment for those pointers. There's no natural lower bound on the
size of the hugepte directories, and with existing setups they already
go as low as 4 entries, which we already pad out to meet our minimum
alignment.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
prev parent reply other threads:[~2009-12-09 2:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-04 7:18 using different format for hugetlbfs Kumar Gala
2009-12-04 8:58 ` Benjamin Herrenschmidt
2009-12-04 14:09 ` Kumar Gala
2009-12-04 21:25 ` Benjamin Herrenschmidt
2009-12-06 3:05 ` Kumar Gala
2009-12-07 1:04 ` Benjamin Herrenschmidt
2009-12-08 2:28 ` David Gibson
2009-12-08 15:44 ` Kumar Gala
2009-12-09 2:00 ` David Gibson [this message]
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=20091209020053.GC5467@yookeroo \
--to=dwg@au1.ibm.com \
--cc=galak@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.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;
as well as URLs for NNTP newsgroup(s).