All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linux-ppc list <linuxppc-dev@ozlabs.org>, David Gibson <dwg@au1.ibm.com>
Subject: Re: using different format for hugetlbfs
Date: Sat, 05 Dec 2009 08:25:42 +1100	[thread overview]
Message-ID: <1259961942.2076.1277.camel@pasglop> (raw)
In-Reply-To: <90D0766D-30A2-4ABE-9707-C7F64A697BFE@kernel.crashing.org>

On Fri, 2009-12-04 at 08:09 -0600, Kumar Gala wrote:
> On Dec 4, 2009, at 2:58 AM, Benjamin Herrenschmidt wrote:
> 
> > On Fri, 2009-12-04 at 01:18 -0600, Kumar Gala wrote:
> >> Ben, David,
> >>
> >> If we want to support true 4G/4G split on ppc32 using the MSB of the
> >> address to determine of the pgd_t is for hugetlbfs isn't going to
> >> work.  Since every pointer in the pgd_t -> pud_t -> pmd_t is point to
> >> at least a 4K page I would think the low order 12-bits should always
> >> be 0.
> >
> > On 32 bit maybe. On 64, the pg/u/md's can be smaller. I don't really
> > want to have a different encoding for both types though.
> 
> What do you mean they can be smaller?  We have some scenario when we  
> dont allocate a full page?  I agree having the encodings be different  
> would be bad.  I'm trying to avoid having it be different between 32  
> bit and 64 (but maybe that will be impossible).

Yes. The intermediary levels are smaller on 64-bit. Also, with hugetlbfs
it can create special levels of various sizes depending on the
requirements to fit a given huge page size. And that would be true of
both 32 and 64-bit in fact.

Cheers,
Ben.

  reply	other threads:[~2009-12-04 21:25 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 [this message]
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

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=1259961942.2076.1277.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=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 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.