public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Mike Kravetz <mike.kravetz@oracle.com>,
	David Hildenbrand <david@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	peterx@redhat.com, Yu Zhao <yuzhao@google.com>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Yang Shi <shy828301@gmail.com>, Hugh Dickins <hughd@google.com>,
	"Kirill A . Shutemov" <kirill@shutemov.name>
Subject: [PATCH RFC v2 2/3] mm: Reorg and declare free spaces in struct folio tails
Date: Mon, 14 Aug 2023 14:44:10 -0400	[thread overview]
Message-ID: <20230814184411.330496-3-peterx@redhat.com> (raw)
In-Reply-To: <20230814184411.330496-1-peterx@redhat.com>

It's not 100% clear on what are the free spaces in the folio tail pages.
Currently we defined fields for only tail pages 1-2 but they're not really
fully occupied.  Add the fields to show what is free, and also reorg them a
bit to make 32/64 bits alignment easy.

Here _free_1_0 should be a constant hole (of 2 bytes) on any system, make
them explicit so people know they can be reused at any time.

_free_1_1 is special and need some attention: this will shift tail page 1's
fields starting from _entire_mapcount to be 4 bytes later.  I don't expect
this change much on real performance - if it will it might be good to have
_entire_mapcount and _nr_pages_mapped to be put on the same 8B alignment,
assuming that _pincount should be rarer to be used in real life.  But in
all cases the movement shouldn't change much on x86 or anything that has
64B cachelines.  This is the major reason why I had this change separate
from the upcoming documentation update patch - it may need some attention,
and when unwanted things happen (I don't expect) we quickly know what's
wrong.

_free_1_2 / _free_2_1 just calls out extra free spaces elsewhere and
shouldn't affect a thing just like _free_1_0.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 include/linux/mm_types.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 3f2b0d46f5d6..829f5adfded1 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -329,11 +329,21 @@ struct folio {
 	/* public: */
 			unsigned char _folio_dtor;
 			unsigned char _folio_order;
+	/* private: 2 bytes can be reused later */
+			unsigned char _free_1_0[2];
+#ifdef CONFIG_64BIT
+	/* 4 bytes can be reused later (64 bits only) */
+			unsigned char _free_1_1[4];
+#endif
+	/* public: */
 			atomic_t _entire_mapcount;
 			atomic_t _nr_pages_mapped;
 			atomic_t _pincount;
 #ifdef CONFIG_64BIT
 			unsigned int _folio_nr_pages;
+	/* private: 4 bytes can be reused later (64 bits only) */
+			unsigned char _free_1_2[4];
+	/* public: */
 #endif
 	/* private: the union with struct page is transitional */
 		};
@@ -355,6 +365,8 @@ struct folio {
 			unsigned long _head_2a;
 	/* public: */
 			struct list_head _deferred_list;
+	/* private: 8 more free bytes for either 32/64 bits */
+			unsigned char _free_2_1[8];
 	/* private: the union with struct page is transitional */
 		};
 		struct page __page_2;
-- 
2.41.0



  parent reply	other threads:[~2023-08-14 18:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-14 18:44 [PATCH RFC v2 0/3] mm: Properly document tail pages for a folio Peter Xu
2023-08-14 18:44 ` [PATCH RFC v2 1/3] mm: Add TAIL_MAPPING_REUSED_MAX Peter Xu
2023-08-14 18:52   ` Peter Xu
2023-08-14 19:08   ` Matthew Wilcox
2023-08-14 19:51     ` Peter Xu
2023-08-14 18:44 ` Peter Xu [this message]
2023-08-14 18:44 ` [PATCH RFC v2 3/3] mm: Proper document tail pages fields for folio Peter Xu
2023-08-14 23:01   ` Randy Dunlap
2023-08-14 19:58 ` [PATCH RFC v2 0/3] mm: Properly document tail pages for a folio Matthew Wilcox
2023-08-14 20:21   ` Peter Xu
2023-08-15  3:45     ` Matthew Wilcox
2023-08-15 19:37       ` Peter Xu
2023-08-15 20:16         ` Matthew Wilcox
2023-08-15 20:39           ` Peter Xu
2023-08-15 21:03             ` Matthew Wilcox
2023-08-14 23:01   ` Randy Dunlap

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=20230814184411.330496-3-peterx@redhat.com \
    --to=peterx@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=ryan.roberts@arm.com \
    --cc=shy828301@gmail.com \
    --cc=willy@infradead.org \
    --cc=yuzhao@google.com \
    /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