All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, Matthew Wilcox <mawilcox@microsoft.com>
Subject: Re: [PATCH v2 6/8] mm: Store compound_dtor / compound_order as bytes
Date: Wed, 20 Dec 2017 16:01:44 -0800	[thread overview]
Message-ID: <20171221000144.GB2980@bombadil.infradead.org> (raw)
In-Reply-To: <20171220153907.7f3994967cba32c6f654982c@linux-foundation.org>

On Wed, Dec 20, 2017 at 03:39:07PM -0800, Andrew Morton wrote:
> On Wed, 20 Dec 2017 07:55:50 -0800 Matthew Wilcox <willy@infradead.org> wrote:
> 
> > From: Matthew Wilcox <mawilcox@microsoft.com>
> > 
> > Neither of these values get even close to 256; compound_dtor is
> > currently at a maximum of 3, and compound_order can't be over 64.
> > No machine has inefficient access to bytes since EV5, and while
> > those are still supported, we don't optimise for them any more.
> 
> So we couild fit compound_dtor and compound_order into a single byte if
> desperate?

Yes ... unless we find another kind of destructor we need for compound pages.

> > This does not shrink struct page, but it removes an ifdef and
> > frees up 2-6 bytes for future use.
> 
> Can we add a little comment telling readers "hey there's a gap here!"?

I think they should have to work to find it!

Here's a replacement patch:

From: Matthew Wilcox <mawilcox@microsoft.com>
Date: Fri, 15 Dec 2017 23:29:11 -0500
Subject: [PATCH] mm: Store compound_dtor / compound_order as bytes

Neither of these values get even close to 256; compound_dtor is
currently at a maximum of 3, and compound_order can't be over 64.
No machine has inefficient access to bytes since EV5, and while
those are still supported, we don't optimise for them any more.
This does not shrink struct page, but it removes an ifdef and
frees up 2-6 bytes for future use.

diff of pahole output:

@@ -34,8 +34,8 @@
 		struct callback_head callback_head;      /*    32    16 */
 		struct {
 			long unsigned int compound_head; /*    32     8 */
-			unsigned int compound_dtor;      /*    40     4 */
-			unsigned int compound_order;     /*    44     4 */
+			unsigned char compound_dtor;     /*    40     1 */
+			unsigned char compound_order;    /*    41     1 */
 		};                                       /*    32    16 */
 	};                                               /*    32    16 */
 	union {

Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Michal Hocko <mhocko@suse.com>
---
 include/linux/mm_types.h | 16 +++-------------
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 5521c9799c50..3e7e99784656 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -136,19 +136,9 @@ struct page {
 			unsigned long compound_head; /* If bit zero is set */
 
 			/* First tail page only */
-#ifdef CONFIG_64BIT
-			/*
-			 * On 64 bit system we have enough space in struct page
-			 * to encode compound_dtor and compound_order with
-			 * unsigned int. It can help compiler generate better or
-			 * smaller code on some archtectures.
-			 */
-			unsigned int compound_dtor;
-			unsigned int compound_order;
-#else
-			unsigned short int compound_dtor;
-			unsigned short int compound_order;
-#endif
+			unsigned char compound_dtor;
+			unsigned char compound_order;
+			/* two/six bytes available here */
 		};
 
 #if defined(CONFIG_TRANSPARENT_HUGEPAGE) && USE_SPLIT_PMD_PTLOCKS
-- 
2.15.1

Seriously, this is only available in the first tail page of a compound
page, so they'll have to go through Kirill to have it assigned to them
... I don't want to pretend like it's available for general use.

--
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>

  reply	other threads:[~2017-12-21  0:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-20 15:55 [PATCH v2 0/8] Restructure struct page Matthew Wilcox
2017-12-20 15:55 ` [PATCH v2 1/8] mm: Align struct page more aesthetically Matthew Wilcox
2017-12-20 15:55 ` [PATCH v2 2/8] mm: De-indent struct page Matthew Wilcox
2017-12-20 15:55 ` [PATCH v2 3/8] mm: Remove misleading alignment claims Matthew Wilcox
2017-12-20 15:55 ` [PATCH v2 4/8] mm: Improve comment on page->mapping Matthew Wilcox
2017-12-20 15:55 ` [PATCH v2 5/8] mm: Introduce _slub_counter_t Matthew Wilcox
2017-12-20 15:55 ` [PATCH v2 6/8] mm: Store compound_dtor / compound_order as bytes Matthew Wilcox
2017-12-20 23:39   ` Andrew Morton
2017-12-21  0:01     ` Matthew Wilcox [this message]
2017-12-20 15:55 ` [PATCH v2 7/8] mm: Document how to use struct page Matthew Wilcox
2017-12-20 15:55 ` [PATCH v2 8/8] mm: Remove reference to PG_buddy Matthew Wilcox

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=20171221000144.GB2980@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=mawilcox@microsoft.com \
    --subject='Re: [PATCH v2 6/8] mm: Store compound_dtor / compound_order as bytes' \
    /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

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.