Re: [PATCH v2 3/8] genirq: soft_moderation: implement fixed moderation

[Luigi Rizzo]

On Tue, Nov 18, 2025 at 12:16 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>
> On Mon, Nov 17 2025 at 20:30, Thomas Gleixner wrote:
> > On Sun, Nov 16 2025 at 18:28, Luigi Rizzo wrote:
> >> +    ms->rounds_left--;
> >> +
> >> +    if (ms->rounds_left > 0) {
> >> +            /* Timer still alive, just call the handlers. */
> >> +            list_for_each_entry_safe(desc, next, &ms->descs, mod.ms_node) {
> >> +                    ms->irq_count += irq_mod_info.count_timer_calls;

> I missed this gem before. How is this supposed to calculate an interrupt
> rate when count_timer_calls is disabled?

FWIW the code is supposed to count the MSI interrupts,
which are the problematic ones.
count_timer_calls was a debugging knob, but understood that
it has no place in the upstream code.

> This polish the Google PoC hackery to death will go nowhere. It's just a
> ginormous waste of time. Not that I care about the time you waste with
> that, but I pretty much care about mine.
>
> That said, start over from scratch and take the feedback into account so

point taken.

> First of all please find some other wording than moderation. That's just
> a randomly diced word without real meaning. Pick something which
> describes what this infrastructure actually does: Adaptive polling, no?

The core feature (with timer_rounds = 0)  is really pure moderation:
disable+start a timer after an interrupt, enable when the timer fires,
no extra calls.

It is only timer_rounds>0 (which as implemented is clearly broken,
and will be removed) that combines moderation + N rounds of timed polling.

> There are a couple of other fundamental questions to answer upfront:
>
>    1) Is this throttle everything on a CPU the proper approach?
>
>       To me this does not make sense. The CPU hogging network adapter or
>       disk drive has no business to delay low frequency interrupts,
>       which might be important, just because.

while there is some shared fate, a low frequency source (with interrupts
more than the adaptive_delay apart) on the same CPU as a high frequency
source, will rarely if ever see any additional delay:
the first interrupt from a source is always served right away,
there is a high chance that the timer fires and the source
is re-enabled before the next interrupt from the low frequency source.

cheers
luigi