From: Christoph Hellwig <hch@infradead.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Fengnan Chang <changfengnan@bytedance.com>,
Luigi Rizzo <lrizzo@google.com>,
Christoph Hellwig <hch@infradead.org>,
Marc Zyngier <maz@kernel.org>,
Luigi Rizzo <rizzo.unipi@gmail.com>,
Paolo Abeni <pabeni@redhat.com>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>,
netdev@vger.kernel.org, linux-nvme@lists.infradead.org,
Guzebing <guzebing@bytedance.com>,
Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH v5 0/7] Global Software Interrupt Moderation (GSIM)
Date: Tue, 8 Sep 2026 23:25:01 -0700 [thread overview]
Message-ID: <aqD7FDvDhiEF_u0N@infradead.org> (raw)
In-Reply-To: <878q5f5tlt.ffs@fw13>
On Sat, Sep 05, 2026 at 10:30:22PM +0200, Thomas Gleixner wrote:
> > it appears that GSIM is only effective in scenarios where multi disks at very high
> > IOPS; in some cases, there was a noticeable performance regression.
> > If there’s something wrong with my configuration, please correct me.
>
> So we have a NVME specific mechanism to tackle the same problem and a
> more generic version which is subsystem "independent".
I'm not sure they tackle the entirely same problem, although they are
very related.
> Can you folks please coordinate and get your act together so that we
> don't end up with two competing mechanisms which make things worse than
> they are now.
This is what I'm trying to get done here. This is the first time I've
seen GSIM as I still try to read lkml, although I usuall fail.
Unfortunately neither the nvme nor block lists were Cced on it,
despite most of the numbers involving NVMe.
> TBH. I despise the NVME is special approach because it's fricking
> obvious that this is _NOT_ a NVME specific issue. But sure NVME is
> special as all other subsystems are special.
Note that we tried to look into generic helpers, Keith tried various
versions using DIMLIB, and we've also considered doing more work in the
block core similar what networking does with NAPI. But we're always
interested common code if it works, glad someone is looking. Although
somewhat more productive suggestions would be helpful.
next prev parent reply other threads:[~2026-09-09 6:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260819124341.4185621-1-lrizzo@google.com>
2026-08-20 7:09 ` [PATCH v5 0/7] Global Software Interrupt Moderation (GSIM) Christoph Hellwig
2026-08-20 7:34 ` Luigi Rizzo
2026-08-20 11:46 ` changfengnan
2026-09-05 20:30 ` Thomas Gleixner
2026-09-09 6:25 ` Christoph Hellwig [this message]
2026-09-09 8:06 ` Luigi Rizzo
2026-09-09 8:52 ` Fengnan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aqD7FDvDhiEF_u0N@infradead.org \
--to=hch@infradead.org \
--cc=bhelgaas@google.com \
--cc=changfengnan@bytedance.com \
--cc=guzebing@bytedance.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lrizzo@google.com \
--cc=maz@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rizzo.unipi@gmail.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox