All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Matt Mackall <mpm@selenic.com>,
	linux-kernel@vger.kernel.org, serue@us.ibm.com,
	"ADAM G. LITKE [imap]" <agl@us.ibm.com>
Subject: Re: [RFC][PATCH 1/5] pagemap: remove file header
Date: Wed, 08 Aug 2007 09:53:35 -0700	[thread overview]
Message-ID: <1186592015.22283.108.camel@localhost> (raw)
In-Reply-To: <1186590879.22283.99.camel@localhost>

On Wed, 2007-08-08 at 09:34 -0700, Dave Hansen wrote:
> On Wed, 2007-08-08 at 02:31 +0100, Alan Cox wrote:
> > The information needed to parse /proc/pid/pagemap can be stuck
> > in /proc/pid/somewherelese. If we ever get page size variations and the
> > like then /proc/pid/ is going to end up with that information anyway for
> > ps and friends to use.
> 
> We do at least have some of this with hugetlbfs.  In fact, the current
> pagemap code bugs out when it hits a huge page area:
> 
> /home/dave/work/linux/2.6/22/lxc/mm/memory.c:117: bad pgd 1d0000e7.
> 
> I'll look at fixing that.

I figure we have three options:

1. ignore huge pages completely
2. teach the ->pte_entry handler that ptes can be different sizes,
   and pass the huge ptes into there
3. let the ->pmd_entry handler (or whatever level we've stuck the huge
   page entry in) handle it
4. create new handlers for large pages, like ->huge_pte_entry.  This
   works for now, but what would we do if we have multiple/variable
   large page sizes?

Any other thoughts?

-- Dave


      reply	other threads:[~2007-08-08 16:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-07 22:33 [RFC][PATCH 1/5] pagemap: remove file header Dave Hansen
2007-08-07 22:33 ` [RFC][PATCH 2/5] pagemap: use PAGE_MASK/PAGE_ALIGN() Dave Hansen
2007-08-08  1:54   ` Matt Mackall
2007-08-07 22:33 ` [RFC][PATCH 3/5] pagemap: remove open-coded sizeof(unsigned long) Dave Hansen
2007-08-07 23:40   ` Matt Mackall
2007-08-07 23:55     ` Dave Hansen
2007-08-08  2:01       ` Matt Mackall
2007-08-07 22:33 ` [RFC][PATCH 4/5] introduce TASK_SIZE_OF() for all arches Dave Hansen
2007-08-08  2:03   ` Matt Mackall
2007-08-08 18:19     ` Dave Hansen
2007-08-07 22:33 ` [RFC][PATCH 5/5] pagemap: add walker for empty areas Dave Hansen
2007-08-08  1:16 ` [RFC][PATCH 1/5] pagemap: remove file header Matt Mackall
2007-08-08  1:31   ` Alan Cox
2007-08-08  3:51     ` Matt Mackall
2007-08-08 16:34     ` Dave Hansen
2007-08-08 16:53       ` Dave Hansen [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=1186592015.22283.108.camel@localhost \
    --to=haveblue@us.ibm.com \
    --cc=agl@us.ibm.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=serue@us.ibm.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 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.