Re: [PATCH v2 11/13] percpu: fix contig hints that are too low

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

Chris - a lot of your replies here seem LLM-generated, and this one in
particular seems especially so.

I've been working evenings and weekends to help with the workload doing
_human_ passes over already AI-generated fixes, so please have a little
consideration for that + keep replies to technical points and as succinct
as possible, thanks.

On Sat, Nov 14, 2026 at 11:57:08AM -0800, Chris Down wrote:
> Hi Lorenzo,
>
> Lorenzo Stoakes (ARM) writes:
> > Secondly, when a free stays within one block,
> > pcpu_block_update_hint_free() passes the end of the free area to the
> > chunk hints as a block offset rather than a chunk offset, so in any block
> > but the first the chunk hints are not updated at all.
>
> Joonwon Kang sent this part earlier this year as "percpu: Fix wrong chunk
> hints update" [1]. It has Dennis' Reviewed-by, but as far as I can tell it
> was never picked up. The rest of that series goes after the scan_hint
> problems by fixing how pcpu_block_update() maintains scan_hint, rather
> than by dropping the promotion, and Dennis was still reviewing that in
> May [2]. It touches the same code as the first case here, so the two won't
> apply on top of each other. It's probably worth adding Joonwon to Cc and
> working out between you which one goes in first.

I'm sorry this is (AI-generated?) nonsense, that's not at all how kernel
development works.

This is a series that got stalled 6 months ago and does things other than
this fix. That doesn't put an indefinite hold on future work in the area,
nor does it give the submitter a veto or say on future work.

So the submitter is welcome to resend and rebase on the fix.

In general, given that this is a drive-by review, with respect, please try
to stick to technical issues, thanks.

>
> > Thirdly, that free area stops at the block boundary, even if the free
> > bits continue into a neighbouring block.
>
> Wasn't this one deliberate? The comment this patch removes says that
> chunk_md->contig_hint may be off by up to a page, as a tradeoff to avoid
> iterating over the block metadata on every free. I don't mind changing
> that, but it'd be good for the changelog to say so, because any free
> whose area reaches a block boundary now ends up in
> pcpu_chunk_refresh_hint().

'I don't mind' :)) for some reason you (or rather persumably your LLM) has
adopted the tone of a component owner which isn't quite appropriate here,
let's maybe try to avoid that in future thanks.

The changelog already covers this, it states that a contig_hint must never be
smaller than the largest free area, and lists this as the third way in
which that is violated.

That it was done on purpose doesn't make it less of a bug - the hint being
too low is what causes pcpu_find_block_fit() to reject a chunk that fits.

>
> > Fix these by always rescanning when a contig_hint is broken, passing the
> > correct offset, and refreshing the chunk hints whenever a free area
> > reaches a block boundary.
>
> Similarly, da3afdd5bb54 ("percpu: use block scan_hint to only scan
> forward") and d33d9f3dd96b ("percpu: use chunk scan_hint to skip some
> scanning") added the scan_hint promotion to avoid exactly these rescans,
> so do you have any numbers for what always rescanning from first_free
> costs on the allocation path?

Nope, I am reworking AI-generated fix patches and this is currently broken,
it doesn't require perf numbers. It needs to be made right first.

In any case the block rescan is bounded at PCPU_BITMAP_BLOCK_BITS and this
issue only happens if a contig_hint is broken.

>
> The result does look right to me, though. From a quick check with the
> hint code lifted into a userspace harness and random allocations and
> frees thrown at it, contig_hint regularly ends up below the largest free
> area before this patch (for both blocks and the chunk) but is fine after
> this patch is applied.

OK thanks.

>
> [1] https://lore.kernel.org/r/20260513085117.1024175-1-joonwonkang@google.com
> [2] https://lore.kernel.org/r/ahVWu38ymnSeLnv3@palisades.local
>
> Thanks!
>
> Chris

--
Cheers, Lorenzo