Answer a report from Sashiko at: https://sashiko.dev/#/patchset/20260901182857.26690-1-mathieu.desnoyers@efficios.com Note that both Sashiko and Claude got it wrong with respect to what was going on there. I took out pen and paper to draw the range situation, and presented the result to Claude through ascii art, which solved the matter. Having two LLMs misguided by the code, I decided to add a visual representation of the approximation ranges to compare_delta() so anyone reviewing this code won't fall into the same traps. This change is documentation only. Signed-off-by: Mathieu Desnoyers Cc: "Paul E. McKenney" Cc: Steven Rostedt Cc: Masami Hiramatsu Cc: Dennis Zhou Cc: Tejun Heo Cc: Christoph Lameter Cc: Martin Liu Cc: David Rientjes Cc: christian.koenig@amd.com Cc: Shakeel Butt Cc: SeongJae Park Cc: Michal Hocko Cc: Johannes Weiner Cc: Sweet Tea Dorminy Cc: Lorenzo Stoakes Cc: Liam R. Howlett Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Christian Brauner Cc: Wei Yang Cc: David Hildenbrand Cc: Miaohe Lin Cc: Al Viro Cc: Yu Zhao Cc: Roman Gushchin Cc: Mateusz Guzik Cc: Matthew Wilcox Cc: Baolin Wang Cc: Aboorva Devarajan Cc: David Carlier Cc: Josh Law Cc: Andrew Morton Cc: linux-mm@kvack.org --- lib/percpu_counter_tree.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/lib/percpu_counter_tree.c b/lib/percpu_counter_tree.c index cd71581f56bb..a8351c53d062 100644 --- a/lib/percpu_counter_tree.c +++ b/lib/percpu_counter_tree.c @@ -457,6 +457,32 @@ long percpu_counter_tree_precise_sum(struct percpu_counter_tree *counter) } EXPORT_SYMBOL_GPL(percpu_counter_tree_precise_sum); +/* + * Each counter's approximation lies within [precise - under, precise + over]: + * + * approx_a range + * <-----------+-----------> + * under_a | over_a + * precise_a + * | approx_b range + * | <-----------+-----------> + * | under_b | over_b + * | precise_b + * | | + * |<------------ gap ------------->| + * ----------------------+--------------------------------+-------------> values + * + * The two ranges are disjoint, and the comparison can return a definitive + * answer, only once the gap exceeds the two facing half-widths: + * + * a below b: gap > over_a + under_b (a's upper edge, b's lower edge) + * a above b: gap > under_a + over_b (a's lower edge, b's upper edge) + * + * When comparing against a plain value, the value has zero width, so the + * margins reduce to that single counter's under and over. + * + * accuracy_neg is used when delta < 0, and accuracy_pos is used when delta >= 0. + */ static int compare_delta(long delta, unsigned long accuracy_neg, unsigned long accuracy_pos) { @@ -494,6 +520,7 @@ int compare_delta(long delta, unsigned long accuracy_neg, unsigned long accuracy */ int percpu_counter_tree_approximate_compare(struct percpu_counter_tree *a, struct percpu_counter_tree *b) { + /* See the range geometry above compare_delta(). */ return compare_delta(percpu_counter_tree_approximate_sum(a) - percpu_counter_tree_approximate_sum(b), a->approx_accuracy_range.over + b->approx_accuracy_range.under, a->approx_accuracy_range.under + b->approx_accuracy_range.over); @@ -549,6 +576,7 @@ int percpu_counter_tree_precise_compare(struct percpu_counter_tree *a, struct pe long delta = count_a - count_b; int res; + /* See the range geometry above compare_delta(). */ res = compare_delta(delta, a->approx_accuracy_range.over + b->approx_accuracy_range.under, a->approx_accuracy_range.under + b->approx_accuracy_range.over); -- 2.43.0