linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Jerome Glisse <jglisse@redhat.com>
Subject: Re: [PATCH 1/3] mm: honor FOLL_GET flag in follow_hugetlb_page
Date: Tue, 07 May 2013 19:00:07 -0400	[thread overview]
Message-ID: <1367967607-vpfj91fc-mutt-n-horiguchi@ah.jp.nec.com> (raw)
In-Reply-To: <CAH3drwbQ91tb=C2D+fNkdPapK75db0yAaWsUrU2A41Rigsuxfg@mail.gmail.com>

On Tue, May 07, 2013 at 06:28:18PM -0400, Jerome Glisse wrote:
> On Tue, May 7, 2013 at 5:53 PM, Naoya Horiguchi
> <n-horiguchi@ah.jp.nec.com> wrote:
> > On Tue, May 07, 2013 at 04:45:54PM -0400, j.glisse@gmail.com wrote:
> >> From: Jerome Glisse <jglisse@redhat.com>
> >>
> >> Do not increase page count if FOLL_GET is not set.
> >>
> >> Signed-off-by: Jerome Glisse <jglisse@redhat.com>
> >> ---
> >>  mm/hugetlb.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> >> index 1a12f5b..5d1e46b 100644
> >> --- a/mm/hugetlb.c
> >> +++ b/mm/hugetlb.c
> >> @@ -2991,7 +2991,9 @@ long follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
> >>  same_page:
> >>               if (pages) {
> >>                       pages[i] = mem_map_offset(page, pfn_offset);
> >> -                     get_page(pages[i]);
> >> +                     if (flags & FOLL_GET) {
> >> +                             get_page_foll(pages[i]);
> >> +                     }
> >>               }
> >>
> >>               if (vmas)
> >> --
> >
> > Hi Jerome,
> >
> > I think that we need to be careful in handling tail pages, because
> > __get_page_tail_foll() uses page->_mapcount as refcount.
> > When you get refcount on a tail page and free the hugepage without
> > putting the *mapcount*, you will hit BUG_ON() in free_huge_page().
> > Yes, this is a very tricky workaround for thp, so to avoid making
> > things too complicated, I think either of the following is better:
> >  - to get refcount only for head pages, or
> >  - to introduce a hugetlbfs variant of get_page_foll().
> 
> Maybe a simpler variant is to just not take any refcount, ie like
> current code if FOLL_GET is set then take refcount on all page wether
> they are head/tail or not. I will resend with that.

Hmm, I think that FOLL_GET flag means "do get_page on page", so
the "not take any refcount" variant seems to make no sense for me.
Would it be better just call without FOLL_GET?

> > BTW, who do you expect is the caller of follow_hugetlb_page()
> > with FOLL_GET (I can't find your subsequent patches 2/3 or 3/3)?
> > I'm interested in this change because in my project it's necessary
> > to implement this for hugepage migration
> > (see https://lkml.org/lkml/2013/3/22/553).
> 
> I can not talk about the patchset yet (and it's not fully cook) but i
> need to be able to get the page without taking reference so without
> the FOLL_GET flag set but i need splitting, well no real splitting, i
> need pfn for each fake sub page of huge page (interested in physical
> address not in the page struct).

If the caller knows the vma is backed by hugetlbfs, we can get pfn of
the tail page by adding page offset (which can be calcurated by the virtual
address with proper huge page mask) to the head page's pfn.

Thanks,
Naoya Horiguchi

--
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>

  reply	other threads:[~2013-05-07 23:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-07 20:45 j.glisse
2013-05-07 21:53 ` Naoya Horiguchi
2013-05-07 22:28   ` Jerome Glisse
2013-05-07 23:00     ` Naoya Horiguchi [this message]
2013-05-07 23:07       ` Jerome Glisse

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=1367967607-vpfj91fc-mutt-n-horiguchi@ah.jp.nec.com \
    --to=n-horiguchi@ah.jp.nec.com \
    --cc=j.glisse@gmail.com \
    --cc=jglisse@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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