linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: keith.busch@intel.com (Keith Busch)
Subject: [PATCH] irq/affinity: Assign all CPUs a vector
Date: Wed, 29 Mar 2017 13:54:15 -0400	[thread overview]
Message-ID: <20170329175415.GD20181@localhost.localdomain> (raw)
In-Reply-To: <6e7a93a7-b0bb-8835-6c49-3eaa3203e1d8@grimberg.me>

On Wed, Mar 29, 2017@08:15:50PM +0300, Sagi Grimberg wrote:
> 
> > The number of vectors to assign needs to be adjusted for each node such
> > that it doesn't exceed the number of CPUs in that node. This patch
> > recalculates the vector assignment per-node so that we don't try to
> > assign more vectors than there are CPUs. When that previously happened,
> > the cpus_per_vec was calculated to be 0, so many vectors had no CPUs
> > assigned. This then goes on to fail to allocate descriptors due to
> > empty masks, leading to an unoptimal spread.
> 
> Can you give a specific (numeric) example where this happens? I'm having
> a little trouble following the logical change here.

Sure, I have a 2-socket server with 16 threads each. I take one CPU
offline in socket 2, so I've 16 threads on socket 1, 15 in socket 2. In
total, 31 threads so requesting 31 vectors.

Currently, vecs_per_node is calculated in the first iteration as 31 / 2, so 15.

ncpus of socket 1 is 16. cpus_per_vec = 16 / 15, so 1 CPU per vector
with one extra.

When iterating the second socket, though, vecs_per_node is incremented
from 15 to 16 (to account for the "extra" from before). However, the
ncpus is only 15, so that iteration calculates:

  cpus_per_vec = 15 / 16

And since that's zero, the remaining 16 vectors are not assigned to any
CPU, and the second socket has no vectors assigned to their CPUs.

  reply	other threads:[~2017-03-29 17:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-28 23:21 [PATCH] irq/affinity: Assign all CPUs a vector Keith Busch
2017-03-29 17:15 ` Sagi Grimberg
2017-03-29 17:54   ` Keith Busch [this message]
2017-03-29 17:50     ` Sagi Grimberg
2017-03-30  8:21 ` Christoph Hellwig
2017-03-30 17:12   ` Keith Busch
2017-04-12  1:33     ` [lkp-robot] [irq/affinity] 13c024422c: fsmark.files_per_sec -4.3% regression kernel test robot
2017-04-12 15:02       ` Keith Busch
2017-03-31 10:59 ` [PATCH] irq/affinity: Assign all CPUs a vector Thomas Gleixner

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=20170329175415.GD20181@localhost.localdomain \
    --to=keith.busch@intel.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;
as well as URLs for NNTP newsgroup(s).