From: Matt Mackall <mpm@selenic.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <andi@firstfloor.org>,
Wu Fengguang <fengguang.wu@intel.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Subject: Re: [PATCH -mmotm] [BUGFIX] pagemap: fix pfn calculation for hugepage
Date: Wed, 24 Mar 2010 11:54:31 -0500 [thread overview]
Message-ID: <1269449671.3552.173.camel@calx> (raw)
In-Reply-To: <20100324054227.GB9336@spritzerA.linux.bs1.fc.nec.co.jp>
On Wed, 2010-03-24 at 14:42 +0900, Naoya Horiguchi wrote:
> When we look into pagemap using page-types with option -p, the value
> of pfn for hugepages looks wrong (see below.)
> This is because pte was evaluated only once for one vma
> although it should be updated for each hugepage. This patch fixes it.
>
> $ page-types -p 3277 -Nl -b huge
> voffset offset len flags
> 7f21e8a00 11e400 1 ___U___________H_G________________
> 7f21e8a01 11e401 1ff ________________TG________________
> ^^^
> 7f21e8c00 11e400 1 ___U___________H_G________________
> 7f21e8c01 11e401 1ff ________________TG________________
> ^^^
>
> One hugepage contains 1 head page and 511 tail pages in x86_64 and
> each two lines represent each hugepage. Voffset and offset mean
> virtual address and physical address in the page unit, respectively.
> The different hugepages should not have the same offset value.
>
> With this patch applied:
>
> $ page-types -p 3386 -Nl -b huge
> voffset offset len flags
> 7fec7a600 112c00 1 ___UD__________H_G________________
> 7fec7a601 112c01 1ff ________________TG________________
> ^^^
> 7fec7a800 113200 1 ___UD__________H_G________________
> 7fec7a801 113201 1ff ________________TG________________
> ^^^
> OK
>
> Changelog:
> - add hugetlb entry walker in mm/pagewalk.c
> (the idea based on Kamezawa-san's patch)
>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Looks good to me.
Acked-by: Matt Mackall <mpm@selenic.com>
--
http://selenic.com : development and support for Mercurial and Linux
WARNING: multiple messages have this Message-ID (diff)
From: Matt Mackall <mpm@selenic.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <andi@firstfloor.org>,
Wu Fengguang <fengguang.wu@intel.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Subject: Re: [PATCH -mmotm] [BUGFIX] pagemap: fix pfn calculation for hugepage
Date: Wed, 24 Mar 2010 11:54:31 -0500 [thread overview]
Message-ID: <1269449671.3552.173.camel@calx> (raw)
In-Reply-To: <20100324054227.GB9336@spritzerA.linux.bs1.fc.nec.co.jp>
On Wed, 2010-03-24 at 14:42 +0900, Naoya Horiguchi wrote:
> When we look into pagemap using page-types with option -p, the value
> of pfn for hugepages looks wrong (see below.)
> This is because pte was evaluated only once for one vma
> although it should be updated for each hugepage. This patch fixes it.
>
> $ page-types -p 3277 -Nl -b huge
> voffset offset len flags
> 7f21e8a00 11e400 1 ___U___________H_G________________
> 7f21e8a01 11e401 1ff ________________TG________________
> ^^^
> 7f21e8c00 11e400 1 ___U___________H_G________________
> 7f21e8c01 11e401 1ff ________________TG________________
> ^^^
>
> One hugepage contains 1 head page and 511 tail pages in x86_64 and
> each two lines represent each hugepage. Voffset and offset mean
> virtual address and physical address in the page unit, respectively.
> The different hugepages should not have the same offset value.
>
> With this patch applied:
>
> $ page-types -p 3386 -Nl -b huge
> voffset offset len flags
> 7fec7a600 112c00 1 ___UD__________H_G________________
> 7fec7a601 112c01 1ff ________________TG________________
> ^^^
> 7fec7a800 113200 1 ___UD__________H_G________________
> 7fec7a801 113201 1ff ________________TG________________
> ^^^
> OK
>
> Changelog:
> - add hugetlb entry walker in mm/pagewalk.c
> (the idea based on Kamezawa-san's patch)
>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Looks good to me.
Acked-by: Matt Mackall <mpm@selenic.com>
--
http://selenic.com : development and support for Mercurial and Linux
--
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:[~2010-03-24 16:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-24 5:42 [PATCH -mmotm] [BUGFIX] pagemap: fix pfn calculation for hugepage Naoya Horiguchi
2010-03-24 5:42 ` Naoya Horiguchi
2010-03-24 5:57 ` KAMEZAWA Hiroyuki
2010-03-24 5:57 ` KAMEZAWA Hiroyuki
2010-03-25 5:55 ` Naoya Horiguchi
2010-03-25 5:55 ` Naoya Horiguchi
2010-03-24 5:58 ` How to reserved all the CPU time for the private computing Zhu, Yijun (NSN - CN/Beijing)
2010-03-24 16:54 ` Matt Mackall [this message]
2010-03-24 16:54 ` [PATCH -mmotm] [BUGFIX] pagemap: fix pfn calculation for hugepage Matt Mackall
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=1269449671.3552.173.camel@calx \
--to=mpm@selenic.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=fengguang.wu@intel.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=nishimura@mxp.nes.nec.co.jp \
/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.