[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMOZA0+NSABcMEgmZxGwA2O9a-uhieLg+W3Q36KrhXKbkHiyNg@mail.gmail.com>
Date: Thu, 15 Jan 2026 23:44:16 +0100
From: Luigi Rizzo <lrizzo@...gle.com>
To: Thomas Gleixner <tglx@...nel.org>
Cc: Marc Zyngier <maz@...nel.org>, Luigi Rizzo <rizzo.unipi@...il.com>,
Paolo Abeni <pabeni@...hat.com>, Andrew Morton <akpm@...ux-foundation.org>,
Sean Christopherson <seanjc@...gle.com>, Jacob Pan <jacob.jun.pan@...ux.intel.com>,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
Bjorn Helgaas <bhelgaas@...gle.com>, Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH v4 3/3] genirq: Adaptive Global Software Interrupt
Moderation (GSIM).
On Thu, Jan 15, 2026 at 11:24 PM Thomas Gleixner <tglx@...nel.org> wrote:
>
> On Thu, Jan 15 2026 at 15:59, Luigi Rizzo wrote:
> > /* Initialize moderation state, used in desc_set_defaults() */
...
> Also this sequence count magic on the read side does not have any real
> value:
>
> > + if (raw_read_seqcount(&irq_mod_info.seq.seqcount) != m->seq) {
>
> Q: What's the gain of this sequence count magic?
The goal is stated in the comment just before the read, see text below.
Surely I can use your suggestion and have the procfs write callback update
all the per-cpu copies and avoid looking for the change on each CPU.
/*
* If any of the configuration parameter changes, read the main ones
* (delay_ns, update_ns), and set the adaptive delay, mod_ns, to the
* maximum value to help converge.
* Without that, the system might be already below target_intr_rate
* because of saturation on the bus (the very problem GSIM is trying
* to address) and that would block the control loop.
* Setting mod_ns to the highest value (if chosen properly) can reduce
* the interrupt rate below target_intr_rate and let the controller
* gradually reach the target.
*/
cheers
luigi
Powered by blists - more mailing lists