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: Mon, 31 Dec 2018 22:30:31 -0800	[thread overview]
Message-ID: <20190101063031.GD6310@bombadil.infradead.org> (raw)
In-Reply-To: <87y385awg6.fsf@linux.ibm.com>

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.

  parent reply	other threads:[~2019-01-01  6:30 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-31 13:42 [PATCH] mm: Introduce page_size() 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 [this message]
2019-01-01 10:11     ` Aneesh Kumar K.V
2019-01-02  3:14       ` Matthew Wilcox
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=20190101063031.GD6310@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;
as well as URLs for NNTP newsgroup(s).