All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Brendan Jackman <jackmanb@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Mel Gorman <mgorman@techsingularity.net>,
	Carlos Song <carlos.song@nxp.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] mm: page_alloc: tighten up find_suitable_fallback()
Date: Fri, 11 Apr 2025 13:07:20 -0400	[thread overview]
Message-ID: <20250411170720.GD366747@cmpxchg.org> (raw)
In-Reply-To: <D93WJ0HYKRGL.1NWTMXWJBWE80@google.com>

On Fri, Apr 11, 2025 at 03:07:01PM +0000, Brendan Jackman wrote:
> On Fri Apr 11, 2025 at 1:45 PM UTC, Johannes Weiner wrote:
> >> -		if (find_suitable_fallback(area, order, migratetype, true) >= 0)
> >> +		if (should_try_claim_block(order, migratetype) &&
> >> +		    find_fallback_migratetype(area, order, migratetype) >= 0)
> >
> > So I agree with pushing the test into the callers. However, I think
> > the name "should_try_claim_block()" is not great for this. It makes
> > sense in the alloc/fallback path, but compaction here doesn't claim
> > anything. It just wants to know if this order + migratetype is
> > eligible under block claiming rules.
> >
> > IMO this would be more readable with the old terminology:
> >
> > 		if (can_claim_block(order, migratetype) &&
> > 		    find_fallback_migratetype(area, order, migratetype) >= 0)
> 
> Sure, that makes sense, here's a modified version of the patch:
> 
> ---
> 
> From 85be0fca4627c5b832a3382c92b6310609e14ca4 Mon Sep 17 00:00:00 2001
> From: Brendan Jackman <jackmanb@google.com>
> Date: Thu, 10 Apr 2025 13:22:58 +0000
> Subject: [PATCH] mm: page_alloc: Split up find_suitable_fallback()
> 
> Now that it's been simplified, it's clear that the bool arg isn't
> needed, callers can just use should_try_claim_block(). Once that logic
> is stripped out, the function becomes very obvious and can get a more
> straightforward name and comment.
> 
> Since should_try_claim_block() is now exported to compaction.c, give it
> a name that makes more sense outside the context of allocation -
> should_claim_block() seems confusing in code that has no interest in
> actually claiming a block.
> 
> Signed-off-by: Brendan Jackman <jackmanb@google.com>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

Thanks!

One minor nit:

> @@ -914,8 +914,9 @@ static inline void init_cma_pageblock(struct page *page)
>  #endif
>  
>  
> -int find_suitable_fallback(struct free_area *area, unsigned int order,
> -			   int migratetype, bool claimable);
> +int find_fallback_migratetype(struct free_area *area, unsigned int order,
> +			      int migratetype);
> +bool can_claim_block(unsigned int order, int start_mt);

Switch those around to match the C file order?

(Just being extra, and this is probably a losing battle, but hey...)


  reply	other threads:[~2025-04-11 17:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-07 18:01 [PATCH 1/2] mm: page_alloc: speed up fallbacks in rmqueue_bulk() Johannes Weiner
2025-04-07 18:01 ` [PATCH 2/2] mm: page_alloc: tighten up find_suitable_fallback() Johannes Weiner
2025-04-10  8:51   ` Vlastimil Babka
2025-04-10 10:50   ` Shivank Garg
2025-04-10 13:55   ` Brendan Jackman
2025-04-11 13:45     ` Johannes Weiner
2025-04-11 15:07       ` Brendan Jackman
2025-04-11 17:07         ` Johannes Weiner [this message]
2025-04-08 17:22 ` [PATCH 1/2] mm: page_alloc: speed up fallbacks in rmqueue_bulk() Brendan Jackman
2025-04-08 18:50   ` Johannes Weiner
2025-04-09 17:30     ` Brendan Jackman
2025-04-10  8:16       ` Vlastimil Babka
2025-04-09  8:02 ` Yunsheng Lin
2025-04-09 14:00   ` Johannes Weiner
2025-04-10  2:02 ` Zi Yan
2025-04-10  7:03 ` [EXT] " Carlos Song
2025-04-10  8:12 ` Vlastimil Babka
2025-04-10 10:48 ` Shivank Garg

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=20250411170720.GD366747@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=carlos.song@nxp.com \
    --cc=jackmanb@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=vbabka@suse.cz \
    /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 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.