From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCDAB33F8B4 for ; Mon, 20 Jul 2026 14:53:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784559196; cv=none; b=G1PnZGTUJWsrKLPd6NLEGcwSU6w+4KCO2+dZw3sClW4te6DzreFm0OOmnAXpgffpvt5JjZOSjtkFICdGXWK+H70qo5s7OxGp5fxgz/K5KSrcMxPNmIAjz+NHaRzqpB+mQlZVDeKi4egBO2375xu8xUFNrDfxqw+winABN9sI+/M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784559196; c=relaxed/simple; bh=QMzpqOBWcB8iZKpOSeHLuF1xRP3XLe7vcquCNskfr6M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=na3ikeSpfyYMX7sov1IumjA8vpP6wbDTb+TVDpDgbx4v6soE137KLZaQrHlZeYg8/8JbsxZs7GUYyCxhqiJvHi6Wzv1sqMa2AL06bdRk0j3ZmWU48/vgavTcHDCQQAB4lz97Nyv+RgxU8l/phIZl3+wNUGnlF0RuMfe+H1Vl+8g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XlGBSUl1; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XlGBSUl1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E8CB31F00A3A; Mon, 20 Jul 2026 14:53:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784559195; bh=H0n99WzJYmk3UtsdjwZNKQMIVvVCi3vB5uugDJ5Cotc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=XlGBSUl1tCfoL/eX6duBkgkUqjkPKvnqA4INhMXKSAJqMNcRo115oQC9ibsx5acVX M+7/3TJujrUuaghSZbHc/xOx43Xr963wZN8E5Vw9Aiz1JCQ1xjLNDnk29zL27oOFIq K8bNN1BtBmgk15vX2cbW60ZwSesDgkOqrs3dYnv/Zmz4Gq6zHrQ3usubZx3xrLU3ZC O60BBcMg31XfD6qVXTgWg102NvLNmSa1NWZAj+slsJjQ4G8fk9x9gj0Tzb9RpG0AqE ZAjUWVmxlCVzLHtlHcYf5TmbGStmngnih68+9KINP3Y/n6gHI+Is3ZyjZn566XRMn1 a9Ra+9wVtXUfQ== Date: Mon, 20 Jul 2026 08:53:11 -0600 From: Keith Busch To: "Zeng, Jun1" Cc: Bart Van Assche , "axboe@kernel.dk" , "hch@lst.de" , "sagi@grimberg.me" , "linux-nvme@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "Shevchenko, Andriy" , "Cao, Gang" , "Jin, Jun I" , "Hu, Yong" Subject: Re: [PATCH v1 0/1] nvme-pci: adaptive interrupt coalescing Message-ID: References: <20260715075703.15578-1-jun1.zeng@intel.com> <3c29b8cb-906c-4c48-89cf-59c676900616@acm.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Jul 20, 2026 at 05:24:12AM +0000, Zeng, Jun1 wrote: > > >On 7/15/26 12:57 AM, Jun Zeng wrote: > > > The IOPS for small IO can be significantly improved when enabling > > > interrupt coalescing in this case. However, in some cases (e.g., big > > > IO for bandwidth or latency-sensitive tests with small IO and small > > > queue depth), interrupt coalescing has side effects. > > > > > > Solution > > > ======== > > > > > > Monitor the IOPS and average queue depth of inflight IO periodically > > > on each NVMe drive and enable/disable interrupt coalescing > > > automatically without user intervention. This feature is enabled by > > > default and can be disabled/enabled through debugfs during runtime. > > > An algorithm like the above can be implemented more efficiently in NVMe controller hardware than in software, isn't it? > > Theoretically, this can be implemented in the NVMe controller's > firmware, but we have no control over the strategies and decisions of > NVMe vendors. We are simply making the best possible optimizations at > the software level. But the coalescing feature as it is is too coarse. There is/was some proposal going through the nvme technical workgroup to improve it. I really haven't had any time to participate in the standards work to say if it's any better, but that's probably the forum to improve such things across vendors. I'm not sure what concern you have about distro support with respect to just controlling this from user space. AFAIK, everything usable has sysfs, and you can't stop passthrough ioctls, so everything you need should be there.