Re: [PATCH] lib: fix compare_delta parameter order in percpu_counter_tree

[Mathieu Desnoyers]

On 2026-03-16 10:15, David CARLIER wrote:
> On Mon, 16 Mar 2026 at 13:53, Mathieu Desnoyers
> <mathieu.desnoyers@xxxxxxxxxxxx> wrote:
> > On 2026-03-16 09:41, David CARLIER wrote:
> > > Sure. For precise_compare_value, the boundary tests extend
> > >     naturally — the function must return the exact result regardless
> > >     of which code path (fast approximate or precise fallback) is taken.
> > >
> > >     For the two-counter APIs, I noticed that the combined accuracy
> > >     is always symmetric: over_a + under_b = under_a + over_b =
> > >     (bs_a + bs_b - 1) * multiplier, so the asymmetric gap test
> > >     doesn't apply there. But boundary tests at the combined accuracy
> > >     limit still provide useful coverage.
> >
> > In order to do a relevant test for the two-counter APIs, we'll need
> > to initialize each of the two counters with different batch sizes.
> > This will ensure that the limits are asymmetric, and therefore allow
> > more precise testing of the limit conditions.
> >
> > Thanks,
> >
> > Mathieu
>
> I looked into this but since accuracy_multiplier is a single global
>    constant, the combined accuracy ends up symmetric regardless of
>    batch sizes. For the two-counter comparison:
>
>      accuracy_pos = over_a + under_b
>      accuracy_neg = under_a + over_b
>
>    Since under = batch_size * M and over = (batch_size - 1) * M,
>    both sides always simplify to the same value. So the asymmetric
>    gap test only applies to the single-value comparison APIs.
>
>    Should I keep the two-counter test with symmetric boundary
>    coverage, or did you have something else in mind?
No, you're right, after simplification they become equivalent.

Thanks,

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com