From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kirill.shutemov@linux.intel.com, Hugh Dickins <hughd@google.com>
Subject: Re: Bloat caused by unnecessary calls to compound_head()?
Date: Mon, 4 Apr 2016 13:39:40 +0300 [thread overview]
Message-ID: <20160404103940.GC21187@node.shutemov.name> (raw)
In-Reply-To: <20160401013329.GB1323@zzz>
On Thu, Mar 31, 2016 at 08:33:29PM -0500, Eric Biggers wrote:
> On Sun, Mar 27, 2016 at 10:46:49PM +0300, Kirill A. Shutemov wrote:
> > The idea is to introduce new type to indicate head page --
> > 'struct head_page' -- it's compatible with struct page on memory layout,
> > but distinct from C point of view. compound_head() should return pointer
> > of that type. For the proof-of-concept I've introduced new helper --
> > compound_head_t().
> >
>
> Well, it's good for optimizing the specific case of mark_page_accessed(). I'm
> more worried about the general level of bloat, since the Page* macros are used
> in so many places. And generating page-flags.h with a script is something to be
> avoided if at all possible.
I think it can be done without generating page-flags.h. We can generate
with preprocessor Head* helpers in addition to Page*. New heplers would
opperate with struct head_page rather than struct page.
> I wasn't following the discussion around the original page-flags patchset. Can
> you point me to a discussion of the benefits of the page "policy" checks --- why
> are they suddenly needed when they weren't before? Or any helpful comments in
> the code?
Recent THP refcounting rework (went into v4.5) made possible mapping part
of huge page with PTEs. Basically, we now have page table entries which
point to tail pages. It means we have tail pages in codepaths where we
haven't before and we need to deal with this.
Many of the flags apply to whole compound page, not a subpage. So we need
to redirect page flag operation to head page.
--
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>
next prev parent reply other threads:[~2016-04-04 10:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-26 18:50 Bloat caused by unnecessary calls to compound_head()? Eric Biggers
2016-03-27 19:46 ` Kirill A. Shutemov
2016-03-27 19:47 ` [PATCH 1/4] page-flags: generate page-flags helpers with script Kirill A. Shutemov
2016-03-27 19:47 ` [PATCH 2/4] mm: introduce struct head_page and compound_head_t Kirill A. Shutemov
2016-03-27 19:47 ` [PATCH 3/4] page-flags: make page flag helpers accept struct head_page Kirill A. Shutemov
2016-03-27 19:47 ` [PATCH 4/4] mm: convert make_page_accessed to use compount_page_t() Kirill A. Shutemov
2016-04-01 1:33 ` Bloat caused by unnecessary calls to compound_head()? Eric Biggers
2016-04-04 10:39 ` Kirill A. Shutemov [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-03-27 20:33 George Spelvin
2016-03-27 20:44 ` 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=20160404103940.GC21187@node.shutemov.name \
--to=kirill@shutemov.name \
--cc=ebiggers3@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).