linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Johannes Weiner <hannes@cmpxchg.org>,
	linux-mm@kvack.org, Matthew Wilcox <willy@infradead.org>
Cc: Kent Overstreet <kent.overstreet@gmail.com>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Michal Hocko <mhocko@suse.com>, Roman Gushchin <guro@fb.com>,
	linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 00/11] PageSlab: eliminate unnecessary compound_head() calls
Date: Mon, 25 Oct 2021 15:49:07 +0200	[thread overview]
Message-ID: <91d4688e-db6e-0ba3-e747-e995f255634b@suse.cz> (raw)
In-Reply-To: <20211012180148.1669685-1-hannes@cmpxchg.org>

On 10/12/21 20:01, Johannes Weiner wrote:
> PageSlab() currently imposes a compound_head() call on all callsites
> even though only very few situations encounter tailpages. This short
> series bubbles tailpage resolution up to the few sites that need it,
> and eliminates it everywhere else.
> 
> This is a stand-alone improvement. However, it's inspired by Willy's
> patches to split struct slab from struct page. Those patches currently
> resolve a slab object pointer to its struct slab as follows:
> 
> 	slab = virt_to_slab(p);		/* tailpage resolution */
> 	if (slab_test_cache(slab)) {	/* slab or page alloc bypass? */
> 		do_slab_stuff(slab);
> 	} else {
> 		page = (struct page *)slab;
> 		do_page_stuff(page);
> 	}
> 
> which makes struct slab an ambiguous type that needs to self-identify
> with the slab_test_cache() test (which in turn relies on PG_slab in
> the flags field shared between page and slab).
> 
> It would be preferable to do:
> 
> 	page = virt_to_head_page(p);	/* tailpage resolution */
> 	if (PageSlab(page)) {		/* slab or page alloc bypass? */
> 		slab = page_slab(page);
> 		do_slab_stuff(slab);
> 	} else {
> 		do_page_stuff(page);
> 	}

I agree with this. Also not fond of introducing setting PG_slab on all tail
pages as willy proposed. But also would like to avoid the tree-wide changes
to PageSlab tailpage resolution that this series is doing.

What we could do is what you suggest above, but the few hotpaths in slab
itself would use a __PageSlab() variant that just doesn't do tailpage
resolution. The rest of tree could keep doing PageSlab with tailpage
resolution for now, and then we can improve on that later. Would that be
acceptable?

With that I'm proposing to take over willy's series (as he asked for that in
the cover letter) which would be modified in the above sense. And maybe in
other ways I can't immediately predict.

But I do want to at least try an approach where we would deal with the
"boundary" functions first (that need to deal with struct page) and then
convert the bulk of "struct page" to "struct slab" at once with help of a
coccinelle semantic patch. I'm hoping that this wouldn't thus be a
"slapdash" conversion, while avoiding a large series of incremental patches
- because the result of such automation wouldn't need such close manual
review as human-written patches do.

> and leave the ambiguity and the need to self-identify with struct
> page, so that struct slab is a strong and unambiguous type, and a
> non-NULL struct slab encountered in the wild is always a valid object
> without the need to check another dedicated flag for validity first.
> 
> However, because PageSlab() currently implies tailpage resolution,
> writing the virt->slab lookup in the preferred way would add yet more
> unnecessary compound_head() call to the hottest MM paths.
> 
> The page flag helpers should eventually all be weaned off of those
> compound_head() calls for their unnecessary overhead alone. But this
> one in particular is now getting in the way of writing code in the
> preferred manner, and bleeding page ambiguity into the new types that
> are supposed to eliminate specifically that. It's ripe for a cleanup.
> 
> Based on v5.15-rc4.
> 
>  arch/ia64/kernel/mca_drv.c |  2 +-
>  drivers/ata/libata-sff.c   |  2 +-
>  fs/proc/page.c             | 12 +++++++-----
>  include/linux/net.h        |  2 +-
>  include/linux/page-flags.h | 10 +++++-----
>  mm/kasan/generic.c         |  2 +-
>  mm/kasan/kasan.h           |  2 +-
>  mm/kasan/report.c          |  4 ++--
>  mm/kasan/report_tags.c     |  2 +-
>  mm/memory-failure.c        |  6 +++---
>  mm/memory.c                |  3 ++-
>  mm/slab.h                  |  2 +-
>  mm/slob.c                  |  4 ++--
>  mm/slub.c                  |  6 +++---
>  mm/util.c                  |  2 +-
>  15 files changed, 32 insertions(+), 29 deletions(-)
> 
> 
> 



      parent reply	other threads:[~2021-10-25 13:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-12 18:01 Johannes Weiner
2021-10-12 18:01 ` [PATCH 01/11] PageSlab: bubble compound_head() into callsites Johannes Weiner
2021-10-12 18:01 ` [PATCH 02/11] PageSlab: eliminate unnecessary compound_head() calls in fs/proc/page Johannes Weiner
2021-10-12 18:01 ` [PATCH 03/11] PageSlab: eliminate unnecessary compound_head() calls in kernel/resource Johannes Weiner
2021-10-12 18:01 ` [PATCH 04/11] PageSlab: eliminate unnecessary compound_head() calls in mm/debug Johannes Weiner
2021-10-12 18:01 ` [PATCH 05/11] PageSlab: eliminate unnecessary compound_head() calls in mm/kasan Johannes Weiner
2021-10-12 18:01 ` [PATCH 06/11] PageSlab: eliminate unnecessary compound_head() call in mm/nommu Johannes Weiner
2021-10-12 18:01 ` [PATCH 07/11] PageSlab: eliminate unnecessary compound_head() call in mm/slab Johannes Weiner
2021-10-12 18:01 ` [PATCH 08/11] PageSlab: eliminate unnecessary compound_head() calls in mm/slab_common Johannes Weiner
2021-10-12 18:01 ` [PATCH 09/11] PageSlab: eliminate unnecessary compound_head() calls in mm/slub Johannes Weiner
2021-10-12 18:01 ` [PATCH 10/11] PageSlab: eliminate unnecessary compound_head() call in mm/usercopy Johannes Weiner
2021-10-12 18:01 ` [PATCH 11/11] PageSlab: eliminate unnecessary compound_head() calls in mm/memcontrol Johannes Weiner
2021-10-12 19:23 ` [PATCH 00/11] PageSlab: eliminate unnecessary compound_head() calls Matthew Wilcox
2021-10-12 20:30   ` Johannes Weiner
2021-10-13  3:19     ` Matthew Wilcox
2021-10-13 13:49       ` Johannes Weiner
2021-10-13 17:55         ` Matthew Wilcox
2021-10-13 19:32           ` Johannes Weiner
2021-10-13 19:57             ` Johannes Weiner
2021-10-14  7:35             ` David Hildenbrand
2021-10-25 13:49 ` Vlastimil Babka [this message]

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=91d4688e-db6e-0ba3-e747-e995f255634b@suse.cz \
    --to=vbabka@suse.cz \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=kent.overstreet@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=willy@infradead.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