All of lore.kernel.org
 help / color / mirror / Atom feed
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	linux-mm@kvack.org, David Rientjes <rientjes@google.com>,
	Andi Kleen <andi@firstfloor.org>,
	Wu Fengguang <fengguang.wu@intel.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] pagemap: avoid splitting thp when reading /proc/pid/pagemap
Date: Thu, 05 Jan 2012 11:28:31 -0500	[thread overview]
Message-ID: <4F05CFAF.9020502@ah.jp.nec.com> (raw)
In-Reply-To: <20120104155042.c24e529b.akpm@linux-foundation.org>

On Wed, Jan 04, 2012 at 03:50:42PM -0800, Andrew Morton wrote:
> On Wed, 21 Dec 2011 17:23:45 -0500
> Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> wrote:
> 
> > Thp split is not necessary if we explicitly check whether pmds are
> > mapping thps or not. This patch introduces the check and the code
> > to generate pagemap entries for pmds mapping thps, which results in
> > less performance impact of pagemap on thp.
> > 
> >
> > ...
> 
> The type choices seem odd:
> 
> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > +static u64 thp_pte_to_pagemap_entry(pte_t pte, int offset)
> > +{
> > +	u64 pme = 0;
> 
> Why are these u64?

I guess (I just copied this type choice from other *pte_to_pagemap_entry()
type functions) it's because each entry in /proc/pid/pagemap is in fixed
sized (64 bit) format as described in the comment above pagemap_read().

> Should we have a pme_t, matching pte_t, pmd_t, etc?

Yes, it makes code's meaning clearer.

> 
> > +	if (pte_present(pte))
> > +		pme = PM_PFRAME(pte_pfn(pte) + offset)
> > +			| PM_PSHIFT(PAGE_SHIFT) | PM_PRESENT;
> > +	return pme;
> > +}
> > +#else
> > +static inline u64 thp_pte_to_pagemap_entry(pte_t pte, int offset)
> > +{
> > +	return 0;
> > +}
> > +#endif
> > +
> >  static int pagemap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
> >  			     struct mm_walk *walk)
> >  {
> > @@ -665,14 +684,34 @@ static int pagemap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
> >  	struct pagemapread *pm = walk->private;
> >  	pte_t *pte;
> >  	int err = 0;
> > -
> > -	split_huge_page_pmd(walk->mm, pmd);
> > +	u64 pfn = PM_NOT_PRESENT;
> 
> Again, why a u64?  pfn's are usually unsigned long.

I think variable's name 'pfn' is wrong rather than type choice
because this variable stores pagemap entry which is not a pure pfn.
There's room for improvement, so I'll try it in the next turn.

Thanks,
Naoya

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	linux-mm@kvack.org, David Rientjes <rientjes@google.com>,
	Andi Kleen <andi@firstfloor.org>,
	Wu Fengguang <fengguang.wu@intel.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] pagemap: avoid splitting thp when reading /proc/pid/pagemap
Date: Thu, 05 Jan 2012 11:28:31 -0500	[thread overview]
Message-ID: <4F05CFAF.9020502@ah.jp.nec.com> (raw)
In-Reply-To: <20120104155042.c24e529b.akpm@linux-foundation.org>

On Wed, Jan 04, 2012 at 03:50:42PM -0800, Andrew Morton wrote:
> On Wed, 21 Dec 2011 17:23:45 -0500
> Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> wrote:
> 
> > Thp split is not necessary if we explicitly check whether pmds are
> > mapping thps or not. This patch introduces the check and the code
> > to generate pagemap entries for pmds mapping thps, which results in
> > less performance impact of pagemap on thp.
> > 
> >
> > ...
> 
> The type choices seem odd:
> 
> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > +static u64 thp_pte_to_pagemap_entry(pte_t pte, int offset)
> > +{
> > +	u64 pme = 0;
> 
> Why are these u64?

I guess (I just copied this type choice from other *pte_to_pagemap_entry()
type functions) it's because each entry in /proc/pid/pagemap is in fixed
sized (64 bit) format as described in the comment above pagemap_read().

> Should we have a pme_t, matching pte_t, pmd_t, etc?

Yes, it makes code's meaning clearer.

> 
> > +	if (pte_present(pte))
> > +		pme = PM_PFRAME(pte_pfn(pte) + offset)
> > +			| PM_PSHIFT(PAGE_SHIFT) | PM_PRESENT;
> > +	return pme;
> > +}
> > +#else
> > +static inline u64 thp_pte_to_pagemap_entry(pte_t pte, int offset)
> > +{
> > +	return 0;
> > +}
> > +#endif
> > +
> >  static int pagemap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
> >  			     struct mm_walk *walk)
> >  {
> > @@ -665,14 +684,34 @@ static int pagemap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
> >  	struct pagemapread *pm = walk->private;
> >  	pte_t *pte;
> >  	int err = 0;
> > -
> > -	split_huge_page_pmd(walk->mm, pmd);
> > +	u64 pfn = PM_NOT_PRESENT;
> 
> Again, why a u64?  pfn's are usually unsigned long.

I think variable's name 'pfn' is wrong rather than type choice
because this variable stores pagemap entry which is not a pure pfn.
There's room for improvement, so I'll try it in the next turn.

Thanks,
Naoya

  reply	other threads:[~2012-01-05 16:29 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-21 22:23 [PATCH 0/4 v2] pagemap handles transparent hugepage Naoya Horiguchi
2011-12-21 22:23 ` Naoya Horiguchi
2011-12-21 22:23 ` [PATCH 1/4] pagemap: avoid splitting thp when reading /proc/pid/pagemap Naoya Horiguchi
2011-12-21 22:23   ` Naoya Horiguchi
2011-12-26  8:26   ` KAMEZAWA Hiroyuki
2011-12-26  8:26     ` KAMEZAWA Hiroyuki
2011-12-30  3:39   ` KOSAKI Motohiro
2011-12-30  3:39     ` KOSAKI Motohiro
2012-01-03 20:07     ` Naoya Horiguchi
2012-01-03 20:07       ` Naoya Horiguchi
2012-01-03 21:06       ` KOSAKI Motohiro
2012-01-03 21:06         ` KOSAKI Motohiro
2012-01-03 21:31         ` Naoya Horiguchi
2012-01-03 21:31           ` Naoya Horiguchi
2012-01-04 23:50   ` Andrew Morton
2012-01-04 23:50     ` Andrew Morton
2012-01-05 16:28     ` Naoya Horiguchi [this message]
2012-01-05 16:28       ` Naoya Horiguchi
2011-12-21 22:23 ` [PATCH 2/4] thp: optimize away unnecessary page table locking Naoya Horiguchi
2011-12-21 22:23   ` Naoya Horiguchi
2011-12-22 13:04   ` Hillf Danton
2011-12-22 16:01     ` Naoya Horiguchi
2011-12-30  3:59   ` KOSAKI Motohiro
2011-12-30  3:59     ` KOSAKI Motohiro
2012-01-03 20:08     ` Naoya Horiguchi
2012-01-03 20:08       ` Naoya Horiguchi
2011-12-21 22:23 ` [PATCH 3/4] pagemap: export KPF_THP Naoya Horiguchi
2011-12-21 22:23   ` Naoya Horiguchi
2011-12-26  8:40   ` KAMEZAWA Hiroyuki
2011-12-26  8:40     ` KAMEZAWA Hiroyuki
2011-12-30  4:01   ` KOSAKI Motohiro
2011-12-30  4:01     ` KOSAKI Motohiro
2012-01-04 23:55   ` Andrew Morton
2012-01-04 23:55     ` Andrew Morton
2011-12-21 22:23 ` [PATCH 4/4] pagemap: document KPF_THP and make page-types aware of it Naoya Horiguchi
2011-12-21 22:23   ` Naoya Horiguchi
2011-12-26  8:42   ` KAMEZAWA Hiroyuki
2011-12-26  8:42     ` KAMEZAWA Hiroyuki
2011-12-30  4:02   ` KOSAKI Motohiro
2011-12-30  4:02     ` KOSAKI Motohiro
2012-01-04 23:57   ` Andrew Morton
2012-01-04 23:57     ` Andrew Morton

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=4F05CFAF.9020502@ah.jp.nec.com \
    --to=n-horiguchi@ah.jp.nec.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=fengguang.wu@intel.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.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.