linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org
Subject: Re: [PATCH] mm: Introduce page_size()
Date: Tue, 1 Jan 2019 19:14:14 -0800	[thread overview]
Message-ID: <20190102031414.GG6310@bombadil.infradead.org> (raw)
In-Reply-To: <87lg447knf.fsf@linux.ibm.com>

On Tue, Jan 01, 2019 at 03:41:00PM +0530, Aneesh Kumar K.V wrote:
> Matthew Wilcox <willy@infradead.org> writes:
> > On Tue, Jan 01, 2019 at 08:57:53AM +0530, Aneesh Kumar K.V wrote:
> >> Matthew Wilcox <willy@infradead.org> writes:
> >> > +/* Returns the number of bytes in this potentially compound page. */
> >> > +static inline unsigned long page_size(struct page *page)
> >> > +{
> >> > +	return (unsigned long)PAGE_SIZE << compound_order(page);
> >> > +}
> >> > +
> >> 
> >> How about compound_page_size() to make it clear this is for
> >> compound_pages? Should we make it work with Tail pages by doing
> >> compound_head(page)?
> >
> > I think that's a terrible idea.  Actually, I think the whole way we handle
> > compound pages is terrible; we should only ever see head pages.  Doing
> > page cache lookups should only give us head pages.  Calling pfn_to_page()
> > should give us the head page.  We should only put head pages into SG lists.
> > Everywhere you see a struct page should only be a head page.
> >
> > I know we're far from that today, and there's lots of work to be done
> > to get there.  But the current state of handling compound pages is awful
> > and confusing.
> >
> > Also, page_size() isn't just for compound pages.  It works for regular
> > pages too.  I'd be open to putting a VM_BUG_ON(PageTail(page)) in it
> > to catch people who misuse it.
> 
> Adding VM_BUG_ON is a good idea.

I'm no longer sure about that.  If someone has a tail page and asks for
page_size(page), I think they want to get PAGE_SIZE back.  Just look at the current users in that patch; they all process page_size() number of bytes, then
move on to the next struct page.

If they somehow happen to have a tail page, then we want them to process
PAGE_SIZE bytes at a time, then move onto the next page, until they hit
a head page.  If calling page_size() on a tail page returned the size
of the entire compound page, then it would process some bytes from pages
which weren't part of this compound page.

So I think the current definition of page_size() is right.

  reply	other threads:[~2019-01-02  3:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-31 13:42 Matthew Wilcox
2018-12-31 23:02 ` Kirill A. Shutemov
2019-01-01  6:39   ` Matthew Wilcox
2019-01-01 20:11     ` Zi Yan
2019-01-02  0:58       ` Matthew Wilcox
2019-01-02  1:16         ` Zi Yan
2019-01-01  3:27 ` Aneesh Kumar K.V
2019-01-01  3:27   ` Aneesh Kumar K.V
2019-01-01  6:30   ` Matthew Wilcox
2019-01-01 10:11     ` Aneesh Kumar K.V
2019-01-02  3:14       ` Matthew Wilcox [this message]
2019-01-02 11:46         ` William Kucharski
2019-01-02 13:09           ` Matthew Wilcox
2019-01-03 10:47             ` William Kucharski
2019-01-01 10:15     ` Aneesh Kumar K.V
2019-05-10 18:12 Matthew Wilcox
2019-05-13 10:56 ` Michal Hocko
2019-05-13 12:43 ` Kirill Tkhai
2019-05-14 11:53   ` William Kucharski
2019-05-22 20:03   ` Andrew Morton
2019-05-23  1:55     ` Matthew Wilcox
2019-05-23 21:33       ` Andrew Morton
2019-05-23 21:44         ` Matthew Wilcox
2019-05-24  6:34           ` Christoph Hellwig

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=20190102031414.GG6310@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --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