From: Jens Axboe <axboe@kernel.dk>
To: Christoph Hellwig <hch@infradead.org>,
David Miller <davem@davemloft.net>
Cc: mroos@linux.ee, linux-scsi@vger.kernel.org,
sparclinux@vger.kernel.org, paulmck@linux.vnet.ibm.com
Subject: Re: Another (ESP?) scsi blk-mq problem on sparc64
Date: Mon, 24 Nov 2014 08:35:46 -0700 [thread overview]
Message-ID: <54735052.7020807@kernel.dk> (raw)
In-Reply-To: <20141124082132.GA22971@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]
On 11/24/2014 01:21 AM, Christoph Hellwig wrote:
> On Fri, Nov 21, 2014 at 02:56:00PM -0500, David Miller wrote:
>> I would suggest looking into the possibility that we allocate the memory
>> using the count of valid cpus, rather than the largest cpu number.
>>
>> That's a common error that runs into problems with discontiguous
>> cpu numbering like Sparc sometimes has.
>
> Yes, that does look like the case. Do you have a good trick on how
> to allocate a map for the highest possible cpu number without first
> iterating the cpu map? I couldn't find something that looks like a
> highest_possible_cpu() helper.
Honestly I think that num_posible_cpus() should return the max of number
of CPUs (weigt), and the highest numbered CPU. It's a pain in the butt
to handle this otherwise.
/* If cpus are offline, map them to first hctx */
map = kzalloc_node(sizeof(*map) * num_possible_cpus(), GFP_KERNEL,
set->numa_node);
is where it goes wrong, assuming Meelis has NR_CPUS set to something <
14, which was the highest numbered CPU, iirc. A construct like:
map = alloc(num_possible_cpus());
for_each_possible_cpu(i)
map[i] = ...
seems like the obvious way to do things, yet it's broken. And not broken
on x86 where we'd find the issue pretty quickly, but on sparc64 where
it'll take a lot longer to run into. It just violates the principle of
least surprise, which is bad for an API.
That said, if there was a helper like Christoph suggested, it'd be a bit
better. And perhaps we can't just modify num_possible_cpus(), we'd need
num_*_cpus() for the other bitmaps, too. That might be breaking other
things...
Meelis, can you try the attached?
--
Jens Axboe
[-- Attachment #2: cpu-pos-count.patch --]
[-- Type: text/x-patch, Size: 634 bytes --]
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 1065d7c65fa1..15da9cc08f64 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -87,10 +87,14 @@ int blk_mq_update_queue_map(unsigned int *map, unsigned int nr_queues)
unsigned int *blk_mq_make_queue_map(struct blk_mq_tag_set *set)
{
+ unsigned int max_cpus;
unsigned int *map;
+ for_each_possible_cpu(max_cpus)
+ ;
+
/* If cpus are offline, map them to first hctx */
- map = kzalloc_node(sizeof(*map) * num_possible_cpus(), GFP_KERNEL,
+ map = kzalloc_node(sizeof(*map) * max_cpus, GFP_KERNEL,
set->numa_node);
if (!map)
return NULL;
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: Christoph Hellwig <hch@infradead.org>,
David Miller <davem@davemloft.net>
Cc: mroos@linux.ee, linux-scsi@vger.kernel.org,
sparclinux@vger.kernel.org, paulmck@linux.vnet.ibm.com
Subject: Re: Another (ESP?) scsi blk-mq problem on sparc64
Date: Mon, 24 Nov 2014 15:35:46 +0000 [thread overview]
Message-ID: <54735052.7020807@kernel.dk> (raw)
In-Reply-To: <20141124082132.GA22971@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]
On 11/24/2014 01:21 AM, Christoph Hellwig wrote:
> On Fri, Nov 21, 2014 at 02:56:00PM -0500, David Miller wrote:
>> I would suggest looking into the possibility that we allocate the memory
>> using the count of valid cpus, rather than the largest cpu number.
>>
>> That's a common error that runs into problems with discontiguous
>> cpu numbering like Sparc sometimes has.
>
> Yes, that does look like the case. Do you have a good trick on how
> to allocate a map for the highest possible cpu number without first
> iterating the cpu map? I couldn't find something that looks like a
> highest_possible_cpu() helper.
Honestly I think that num_posible_cpus() should return the max of number
of CPUs (weigt), and the highest numbered CPU. It's a pain in the butt
to handle this otherwise.
/* If cpus are offline, map them to first hctx */
map = kzalloc_node(sizeof(*map) * num_possible_cpus(), GFP_KERNEL,
set->numa_node);
is where it goes wrong, assuming Meelis has NR_CPUS set to something <
14, which was the highest numbered CPU, iirc. A construct like:
map = alloc(num_possible_cpus());
for_each_possible_cpu(i)
map[i] = ...
seems like the obvious way to do things, yet it's broken. And not broken
on x86 where we'd find the issue pretty quickly, but on sparc64 where
it'll take a lot longer to run into. It just violates the principle of
least surprise, which is bad for an API.
That said, if there was a helper like Christoph suggested, it'd be a bit
better. And perhaps we can't just modify num_possible_cpus(), we'd need
num_*_cpus() for the other bitmaps, too. That might be breaking other
things...
Meelis, can you try the attached?
--
Jens Axboe
[-- Attachment #2: cpu-pos-count.patch --]
[-- Type: text/x-patch, Size: 634 bytes --]
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 1065d7c65fa1..15da9cc08f64 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -87,10 +87,14 @@ int blk_mq_update_queue_map(unsigned int *map, unsigned int nr_queues)
unsigned int *blk_mq_make_queue_map(struct blk_mq_tag_set *set)
{
+ unsigned int max_cpus;
unsigned int *map;
+ for_each_possible_cpu(max_cpus)
+ ;
+
/* If cpus are offline, map them to first hctx */
- map = kzalloc_node(sizeof(*map) * num_possible_cpus(), GFP_KERNEL,
+ map = kzalloc_node(sizeof(*map) * max_cpus, GFP_KERNEL,
set->numa_node);
if (!map)
return NULL;
next prev parent reply other threads:[~2014-11-24 15:35 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-14 11:32 Another (ESP?) scsi blk-mq problem on sparc64 Meelis Roos
2014-11-14 11:32 ` Meelis Roos
2014-11-14 16:58 ` Christoph Hellwig
2014-11-14 16:58 ` Christoph Hellwig
2014-11-14 17:01 ` Jens Axboe
2014-11-14 17:01 ` Jens Axboe
2014-11-14 19:35 ` Meelis Roos
2014-11-14 19:35 ` Meelis Roos
2014-11-14 19:42 ` Jens Axboe
2014-11-14 19:42 ` Jens Axboe
2014-11-14 22:59 ` Meelis Roos
2014-11-14 22:59 ` Meelis Roos
2014-11-14 23:29 ` Jens Axboe
2014-11-14 23:29 ` Jens Axboe
2014-11-15 6:48 ` Meelis Roos
2014-11-15 6:48 ` Meelis Roos
2014-11-15 15:31 ` Jens Axboe
2014-11-15 15:31 ` Jens Axboe
2014-11-20 6:01 ` Christoph Hellwig
2014-11-20 6:01 ` Christoph Hellwig
2014-11-21 19:56 ` David Miller
2014-11-21 19:56 ` David Miller
2014-11-24 8:21 ` Christoph Hellwig
2014-11-24 8:21 ` Christoph Hellwig
2014-11-24 15:35 ` Jens Axboe [this message]
2014-11-24 15:35 ` Jens Axboe
2014-11-24 16:22 ` Paul E. McKenney
2014-11-24 16:22 ` Paul E. McKenney
2014-11-24 17:16 ` Jens Axboe
2014-11-24 17:16 ` Jens Axboe
2014-11-24 17:31 ` Paul E. McKenney
2014-11-24 17:31 ` Paul E. McKenney
2014-11-24 17:33 ` Jens Axboe
2014-11-24 17:33 ` Jens Axboe
2014-11-24 17:44 ` Paul E. McKenney
2014-11-24 17:44 ` Paul E. McKenney
2014-11-24 21:56 ` David Miller
2014-11-24 21:56 ` David Miller
2014-11-24 22:01 ` Jens Axboe
2014-11-24 22:01 ` Jens Axboe
2014-11-24 22:09 ` David Miller
2014-11-24 22:09 ` David Miller
2014-11-24 22:20 ` Jens Axboe
2014-11-24 22:20 ` Jens Axboe
2014-11-24 22:23 ` mroos
2014-11-24 22:23 ` mroos
2014-11-24 22:28 ` David Miller
2014-11-24 22:28 ` David Miller
2015-01-29 7:53 ` Meelis Roos
2015-01-29 7:53 ` Meelis Roos
2015-01-29 16:37 ` Jens Axboe
2015-01-29 16:37 ` Jens Axboe
2015-09-04 8:33 ` Meelis Roos
2015-09-04 8:33 ` Meelis Roos
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=54735052.7020807@kernel.dk \
--to=axboe@kernel.dk \
--cc=davem@davemloft.net \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mroos@linux.ee \
--cc=paulmck@linux.vnet.ibm.com \
--cc=sparclinux@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.