All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Hugh Dickins <hughd@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: avoid tail page refcounting on non-THP compound pages
Date: Thu, 26 Mar 2015 00:56:33 +0200	[thread overview]
Message-ID: <20150325225633.GA14549@node.dhcp.inet.fi> (raw)
In-Reply-To: <alpine.LSU.2.11.1503251545510.4490@eggly.anvils>

On Wed, Mar 25, 2015 at 03:48:48PM -0700, Hugh Dickins wrote:
> On Wed, 25 Mar 2015, Hugh Dickins wrote:
> > On Thu, 26 Mar 2015, Kirill A. Shutemov wrote:
> > 
> > > THP uses tail page refcounting to be able to split huge page at any
> > > time. Tail page refcounting is not needed for rest users of compound
> > > pages and it's harmful because of overhead.
> > > 
> > > We try to exclude non-THP pages from tail page refcounting using
> > > __compound_tail_refcounted() check. It excludes most common non-THP
> > > compound pages: SL*B and hugetlb, but it doesn't catch rest of
> > > __GFP_COMP users -- drivers.
> > > 
> > > And it's not only about overhead.
> > > 
> > > Drivers might want to use compound pages to get refcounting semantics
> > > suitable for mapping high-order pages to userspace. But tail page
> > > refcounting breaks it.
> > > 
> > > Tail page refcounting uses ->_mapcount in tail pages to store GUP pins
> > > on them. It means GUP pins would affect page_mapcount() for tail pages.
> > > It's not a problem for THP, because it never maps tail pages. But unlike
> > > THP, drivers map parts of compound pages with PTEs and it makes
> > > page_mapcount() be called for tail pages.
> > > 
> > > In particular, GUP pins would shift PSS up and affect /proc/kpagecount
> > > for such pages. But, I'm not aware about anything which can lead to
> > > crash or other serious misbehaviour.
> > > 
> > > Since currently all THP pages are anonymous and all drivers pages are
> > > not, we can fix the __compound_tail_refcounted() check by requiring
> > > PageAnon() to enable tail page refcounting.
> > > 
> > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > 
> > Acked-by: Hugh Dickins <hughd@google.com>
> 
> Oh, hold on a moment: does this actually build in a tree without your
> page-flags.h consolidation?  It didn't when I tried to add a PageAnon
> test there for my series against v3.19, has something changed in v4.0?

No. I haven't tried to build it without my patchset, but it seems it
wouldn't.

Just check: it would build for me on top of [PATCH 01/16], you've acked.

-- 
 Kirill A. Shutemov

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

WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Hugh Dickins <hughd@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: avoid tail page refcounting on non-THP compound pages
Date: Thu, 26 Mar 2015 00:56:33 +0200	[thread overview]
Message-ID: <20150325225633.GA14549@node.dhcp.inet.fi> (raw)
In-Reply-To: <alpine.LSU.2.11.1503251545510.4490@eggly.anvils>

On Wed, Mar 25, 2015 at 03:48:48PM -0700, Hugh Dickins wrote:
> On Wed, 25 Mar 2015, Hugh Dickins wrote:
> > On Thu, 26 Mar 2015, Kirill A. Shutemov wrote:
> > 
> > > THP uses tail page refcounting to be able to split huge page at any
> > > time. Tail page refcounting is not needed for rest users of compound
> > > pages and it's harmful because of overhead.
> > > 
> > > We try to exclude non-THP pages from tail page refcounting using
> > > __compound_tail_refcounted() check. It excludes most common non-THP
> > > compound pages: SL*B and hugetlb, but it doesn't catch rest of
> > > __GFP_COMP users -- drivers.
> > > 
> > > And it's not only about overhead.
> > > 
> > > Drivers might want to use compound pages to get refcounting semantics
> > > suitable for mapping high-order pages to userspace. But tail page
> > > refcounting breaks it.
> > > 
> > > Tail page refcounting uses ->_mapcount in tail pages to store GUP pins
> > > on them. It means GUP pins would affect page_mapcount() for tail pages.
> > > It's not a problem for THP, because it never maps tail pages. But unlike
> > > THP, drivers map parts of compound pages with PTEs and it makes
> > > page_mapcount() be called for tail pages.
> > > 
> > > In particular, GUP pins would shift PSS up and affect /proc/kpagecount
> > > for such pages. But, I'm not aware about anything which can lead to
> > > crash or other serious misbehaviour.
> > > 
> > > Since currently all THP pages are anonymous and all drivers pages are
> > > not, we can fix the __compound_tail_refcounted() check by requiring
> > > PageAnon() to enable tail page refcounting.
> > > 
> > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > 
> > Acked-by: Hugh Dickins <hughd@google.com>
> 
> Oh, hold on a moment: does this actually build in a tree without your
> page-flags.h consolidation?  It didn't when I tried to add a PageAnon
> test there for my series against v3.19, has something changed in v4.0?

No. I haven't tried to build it without my patchset, but it seems it
wouldn't.

Just check: it would build for me on top of [PATCH 01/16], you've acked.

-- 
 Kirill A. Shutemov

  reply	other threads:[~2015-03-25 22:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-25 22:41 [PATCH] mm: avoid tail page refcounting on non-THP compound pages Kirill A. Shutemov
2015-03-25 22:41 ` Kirill A. Shutemov
2015-03-25 22:45 ` Hugh Dickins
2015-03-25 22:45   ` Hugh Dickins
2015-03-25 22:48   ` Hugh Dickins
2015-03-25 22:48     ` Hugh Dickins
2015-03-25 22:56     ` Kirill A. Shutemov [this message]
2015-03-25 22:56       ` Kirill A. Shutemov
2015-03-25 23:09       ` Hugh Dickins
2015-03-25 23:09         ` Hugh Dickins
  -- strict thread matches above, loose matches on Subject: below --
2015-03-26 15:27 Kirill A. Shutemov
2015-03-26 15:52 ` Kirill A. Shutemov

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=20150325225633.GA14549@node.dhcp.inet.fi \
    --to=kirill@shutemov.name \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=kirill.shutemov@linux.intel.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 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.