From: Eric Biggers <ebiggers3@gmail.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
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: Thu, 31 Mar 2016 20:33:29 -0500 [thread overview]
Message-ID: <20160401013329.GB1323@zzz> (raw)
In-Reply-To: <20160327194649.GA9638@node.shutemov.name>
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 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?
--
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: Eric Biggers <ebiggers3@gmail.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
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: Thu, 31 Mar 2016 20:33:29 -0500 [thread overview]
Message-ID: <20160401013329.GB1323@zzz> (raw)
In-Reply-To: <20160327194649.GA9638@node.shutemov.name>
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 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?
next prev parent reply other threads:[~2016-04-01 1:33 UTC|newest]
Thread overview: 20+ 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-26 18:50 ` Eric Biggers
2016-03-27 19:46 ` Kirill A. Shutemov
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 ` 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 ` 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 ` 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-03-27 19:47 ` Kirill A. Shutemov
2016-04-01 1:33 ` Eric Biggers [this message]
2016-04-01 1:33 ` Bloat caused by unnecessary calls to compound_head()? Eric Biggers
2016-04-04 10:39 ` Kirill A. Shutemov
2016-04-04 10:39 ` Kirill A. Shutemov
-- strict thread matches above, loose matches on Subject: below --
2016-03-27 20:33 George Spelvin
2016-03-27 20:33 ` George Spelvin
2016-03-27 20:44 ` Kirill A. Shutemov
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=20160401013329.GB1323@zzz \
--to=ebiggers3@gmail.com \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--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.