linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: sagi@grimberg.me, linux-nvme@lists.infradead.org
Subject: Re: [PATCH 3/3] nvme-pci: reshuffle nvme_queue members
Date: Mon, 4 May 2020 11:18:32 -0700	[thread overview]
Message-ID: <20200504181832.GA2278084@dhcp-10-100-145-180.wdl.wdc.com> (raw)
In-Reply-To: <20200501150815.GA22665@redsun51.ssa.fujisawa.hgst.com>

On Sat, May 02, 2020 at 12:08:15AM +0900, Keith Busch wrote:
> On Fri, May 01, 2020 at 02:57:04PM +0200, Christoph Hellwig wrote:
> > On Mon, Apr 27, 2020 at 04:52:43PM -0700, Keith Busch wrote:
> > > All the io path hot members can fit within the first 64-bytes, which is
> > > a common cacheline. Order the members of this struct so those members
> > > fit in and align to that window.
> > 
> > Do we even want to share a cacheline for the submission vs completion
> > path?  I know other places try to keep the deliberately separate.
> 
> We usually complete on the same CPU that submitted, so it appears
> beneficial to fit both sides in the same line. I'll try it out both
> ways, though I don't think I'll be able to measure a difference.

If there are more cpus than queues, there is a real benefit to
separating submit and complete into different cache lines, otherwise
they invalidate each other when submissions occur on cpus different than
completions. The extra space provides more flexibility arranging the
struct, so I'll experiment with that a bit more.

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  parent reply	other threads:[~2020-05-04 18:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27 23:52 [PATCH 1/3] nvme-pci: clear shadow doorbell memory on resets Keith Busch
2020-04-27 23:52 ` [PATCH 2/3] nvme-pci: remove cached shadow doorbell offsets Keith Busch
2020-04-30  6:36   ` Dongli Zhang
2020-04-30 19:07     ` Keith Busch
2020-05-01 12:54   ` Christoph Hellwig
2021-10-04  9:42   ` John Levon
2020-04-27 23:52 ` [PATCH 3/3] nvme-pci: reshuffle nvme_queue members Keith Busch
2020-05-01 12:57   ` Christoph Hellwig
2020-05-01 15:08     ` Keith Busch
2020-05-01 15:12       ` Christoph Hellwig
2020-05-01 15:23         ` Keith Busch
2020-05-04 18:18       ` Keith Busch [this message]
2020-05-01 12:49 ` [PATCH 1/3] nvme-pci: clear shadow doorbell memory on resets Christoph Hellwig
2021-10-04  9:35 ` John Levon
2021-10-06 12:07   ` Keith Busch
2021-10-06 16:05     ` John Levon

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=20200504181832.GA2278084@dhcp-10-100-145-180.wdl.wdc.com \
    --to=kbusch@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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;
as well as URLs for NNTP newsgroup(s).