public inbox for [email protected]
 help / color / mirror / Atom feed
From: Matthew Wilcox <[email protected]>
To: Peter Xu <[email protected]>
Cc: Andrew Morton <[email protected]>,
	Jens Axboe <[email protected]>,
	[email protected], [email protected]
Subject: Re: [PATCH 8/9] mm: Rearrange page flags
Date: Tue, 15 Aug 2023 21:07:30 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <ZNvQ4EbQh/aAwK8L@x1n>

On Tue, Aug 15, 2023 at 03:24:16PM -0400, Peter Xu wrote:
> On Tue, Aug 15, 2023 at 04:26:44AM +0100, Matthew Wilcox (Oracle) wrote:
> > +++ b/include/linux/page-flags.h
> > @@ -99,13 +99,15 @@
> >   */
> >  enum pageflags {
> >  	PG_locked,		/* Page is locked. Don't touch. */
> > +	PG_writeback,		/* Page is under writeback */
> >  	PG_referenced,
> >  	PG_uptodate,
> >  	PG_dirty,
> >  	PG_lru,
> > +	PG_head,		/* Must be in bit 6 */
> 
> Could there be some explanation on "must be in bit 6" here?

Not on this line, no.  You get 40-50 characters to say something useful.
Happy to elaborate further in some other comment or in the commit log,
but not on this line.

The idea behind all of this is that _folio_order moves into the bottom
byte of _flags_1.  Because the order can never be greater than 63 (and
in practice I think the largest we're going to see is about 30 -- a 16GB
hugetlb page on some architectures), we know that PG_head and PG_waiters
will be clear, so we can write (folio->_flags_1 & 0xff) and the compiler
will just load a byte; it won't actually load the word and mask it.

We can't move PG_head any lower, or we'll risk having a tail page with
PG_head set (which can happen with the vmemmmap optimisation, but eugh).
And we don't want to move it any higher because then we'll have a flag
that cannot be reused in a tail page.  Bit 6 is the perfect spot for it.

  reply	other threads:[~2023-08-15 20:08 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-15  3:26 [PATCH 0/9] Remove _folio_dtor and _folio_order Matthew Wilcox (Oracle)
2023-08-15  3:26 ` [PATCH 1/9] io_uring: Stop calling free_compound_page() Matthew Wilcox (Oracle)
2023-08-15  7:33   ` David Hildenbrand
2023-08-15 15:00   ` Jens Axboe
2023-08-15 15:36     ` Matthew Wilcox
2023-08-15  3:26 ` [PATCH 2/9] mm: Call the hugetlb destructor directly Matthew Wilcox (Oracle)
2023-08-15  7:36   ` David Hildenbrand
2023-08-15  3:26 ` [PATCH 3/9] mm: Call free_transhuge_folio() directly from destroy_large_folio() Matthew Wilcox (Oracle)
2023-08-15  6:13   ` kernel test robot
2023-08-15  7:40   ` David Hildenbrand
2023-08-15 14:06     ` Matthew Wilcox
2023-08-15  8:09   ` kernel test robot
2023-08-15  3:26 ` [PATCH 4/9] mm: Make free_compound_page() static Matthew Wilcox (Oracle)
2023-08-15  7:47   ` David Hildenbrand
2023-08-15  7:48     ` David Hildenbrand
2023-08-15  3:26 ` [PATCH 5/9] mm: Remove free_compound_page() Matthew Wilcox (Oracle)
2023-08-15  7:48   ` David Hildenbrand
2023-08-15  3:26 ` [PATCH 6/9] mm: Remove HUGETLB_PAGE_DTOR Matthew Wilcox (Oracle)
2023-08-15  7:50   ` David Hildenbrand
2023-08-15  3:26 ` [PATCH 7/9] mm: Add deferred_list page flag Matthew Wilcox (Oracle)
2023-08-15  7:54   ` David Hildenbrand
2023-08-15 15:32     ` Matthew Wilcox
2023-08-15 16:40       ` David Hildenbrand
2023-08-15 17:06         ` Matthew Wilcox
2023-08-15 17:27           ` David Hildenbrand
2023-08-15 19:58             ` Matthew Wilcox
2023-08-16  3:14               ` Matthew Wilcox
2023-08-16 10:12                 ` David Hildenbrand
2023-08-16 12:05                   ` Matthew Wilcox
2023-08-16 12:34                     ` David Hildenbrand
2023-08-16  9:55               ` David Hildenbrand
2023-08-15  3:26 ` [PATCH 8/9] mm: Rearrange page flags Matthew Wilcox (Oracle)
2023-08-15  4:30   ` Yosry Ahmed
2023-08-15 19:24   ` Peter Xu
2023-08-15 20:07     ` Matthew Wilcox [this message]
2023-08-15 22:31       ` Yosry Ahmed
2023-08-15 23:01         ` Matthew Wilcox
2023-08-15 23:33           ` Yosry Ahmed
2023-08-15  3:26 ` [PATCH 9/9] mm: Free up a word in the first tail page Matthew Wilcox (Oracle)
2023-08-15  7:59   ` David Hildenbrand
2023-08-15 11:39     ` Matthew Wilcox
2023-08-15 19:21   ` Peter Xu

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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