Re: [PATCH 5/7] mm/mglru: use explicit tier range in read_ctrl_pos()

Kairui Song <[email protected]>
Newsgroups org.kernel.vger.cgroups,org.kernel.vger.linux-kernel,org.kvack.linux-mm
Message-ID <CAMgjq7DOAazz98uM+qXqgka2Y6ZzshjBnQ1N5TJ7=gCR6FttBQ@mail.gmail.com>
On Thu, Aug 20, 2026 at 10:34 AM Ridong Chen <[email protected]> wrote:
> On 8/18/2026 1:38 PM, Kairui Song via B4 Relay wrote:
> > From: Kairui Song <[email protected]>
> >
> > read_ctrl_pos() encodes the tier range in a single "tier" parameter
> > via "tier % MAX_NR_TIERS" as the start and "min(tier, MAX_NR_TIERS-1)"
> > as the end. This is hard to follow, maintain, or extend. Tier values
> > 0..3 select a single tier, while tier == MAX_NR_TIERS selects the
> > full range.
> >
> > Replace it with explicit (tier_min, tier_max) parameters using a
> > closed [tier_min, tier_max] interval, and add LRU_TIER_MIN and
> > LRU_TIER_MAX for the tier bounds. The call sites now become
> > self-documenting:
> >
> >    - get_tier_idx:   (LRU_TIER_MIN, LRU_TIER_MIN) for the first tier,
> >                      (tier, tier) for each subsequent tier
> >    - get_type_to_scan: (LRU_TIER_MIN, LRU_TIER_MAX) for the full range
> >
> > No functional change.
> >
>
> Just like LRU_GEN_MAX and MAX_NR_GENS issue.
> Why do we have to add LRU_TIER_MAX, can we just use [tier_min, MAX_NR_TIERS)?
>

I did that previously, but reviewer suggested LRU_TIER_MAX, :D

I'm fine either way, it's really trivial.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.