Linux NFS development
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Chuck Lever III <chuck.lever@oracle.com>,
	Neil Brown <neilb@suse.de>, Jeff Layton <jlayton@kernel.org>,
	Trond Myklebust <trondmy@hammerspace.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: knfsd performance
Date: Tue, 18 Jun 2024 22:47:16 -0700	[thread overview]
Message-ID: <ZnJw5HAK0N3q5LvS@infradead.org> (raw)
In-Reply-To: <ZnJI7Em5clnyWDU6@dread.disaster.area>

On Wed, Jun 19, 2024 at 12:56:44PM +1000, Dave Chinner wrote:
> I'm not sure that the NFS server needs to reinvent the wheel here...
> 
> > Network devices (and storage devices) are affined to one
> > NUMA node.
> 
> NVMe storage devices don't need to be affine to the node. They just
> need to have a hardware queue assigned to each node so that
> node-local IO always hits the same hardware queue and gets
> completion interrupts returned to that same node.
> 
> And, yes, this is something that still has to be configured
> manually, too.

For NVMe no manual configuration is required.  It uses the
blk_mq_pci_map_queues helper to spread the queues around
optimally.  If enough queues are available every core gets
one, else they are spread so that close cores share queues.


  reply	other threads:[~2024-06-19  5:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18 18:32 knfsd performance Trond Myklebust
2024-06-18 18:40 ` Chuck Lever III
2024-06-18 19:29   ` Trond Myklebust
2024-06-18 19:39     ` Chuck Lever III
2024-06-18 19:50       ` Trond Myklebust
2024-06-18 19:54         ` Chuck Lever III
2024-06-18 20:16           ` Jeff Layton
2024-06-18 23:17             ` NeilBrown
2024-06-18 23:26               ` Chuck Lever III
2024-06-18 23:33                 ` Jeff Layton
2024-06-18 23:51                   ` Chuck Lever III
2024-06-19  2:56                 ` Dave Chinner
2024-06-19  5:47                   ` Christoph Hellwig [this message]
2024-06-19 13:44                   ` Chuck Lever III
2024-06-19 21:16                   ` NeilBrown
2024-06-19  0:42           ` Dave Chinner
2024-06-19  1:01             ` NeilBrown
2024-06-19 21:25               ` NeilBrown
2024-06-20  2:29                 ` Dave Chinner
2024-06-20 10:18                   ` Jeff Layton
2024-06-20 21:39                     ` NeilBrown
2024-06-20 18:33                   ` Chuck Lever III
2024-06-20 22:04                     ` NeilBrown
2024-06-20 23:57                       ` Trond Myklebust
2024-06-18 19:38 ` Jeff Layton
2024-06-18 23:12   ` NeilBrown

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=ZnJw5HAK0N3q5LvS@infradead.org \
    --to=hch@infradead.org \
    --cc=chuck.lever@oracle.com \
    --cc=david@fromorbit.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=trondmy@hammerspace.com \
    /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