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.