From: Jens Axboe <axboe@kernel.dk>
To: Meelis Roos <mroos@linux.ee>, David Miller <davem@davemloft.net>
Cc: paulmck@linux.vnet.ibm.com, hch@infradead.org,
linux-scsi@vger.kernel.org, sparclinux@vger.kernel.org
Subject: Re: Another (ESP?) scsi blk-mq problem on sparc64
Date: Thu, 29 Jan 2015 08:37:51 -0800 [thread overview]
Message-ID: <54CA61DF.30807@kernel.dk> (raw)
In-Reply-To: <alpine.LRH.2.11.1501290952340.25245@math.ut.ee>
[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]
On 01/28/2015 11:53 PM, Meelis Roos wrote:
> On Mon, 24 Nov 2014, David Miller wrote:
>
>> From: mroos@linux.ee
>> Date: Tue, 25 Nov 2014 00:23:20 +0200 (EET)
>>
>>>>>>> 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.
>>>>>
>>>>> Hear, hear!!! That would make my life easier, and would make this sort
>>>>> of problem much less likely to occur!
>>>>
>>>> How about this one?
>>>
>>> It make the machine work.
>>
>> Thanks for testing!
>>
>
> What's the status of this fix? It is still not applied on yesterdays
> 3.19.0-rc6-00105-gc59c961 git...
Hmm, I thought commit a33c1ba29138 took care of it... Does the attached
work?
--
Jens Axboe
[-- Attachment #2: map-sz.patch --]
[-- Type: text/x-patch, Size: 644 bytes --]
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 5f13f4d0bcce..527d315dc1a5 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -88,10 +88,11 @@ 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 *map;
+ size_t sz;
/* If cpus are offline, map them to first hctx */
- map = kzalloc_node(sizeof(*map) * nr_cpu_ids, GFP_KERNEL,
- set->numa_node);
+ sz = max_t(unsigned int, nr_cpu_ids, num_possible_cpus());
+ map = kzalloc_node(sizeof(*map) * sz, GFP_KERNEL, set->numa_node);
if (!map)
return NULL;
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: Meelis Roos <mroos@linux.ee>, David Miller <davem@davemloft.net>
Cc: paulmck@linux.vnet.ibm.com, hch@infradead.org,
linux-scsi@vger.kernel.org, sparclinux@vger.kernel.org
Subject: Re: Another (ESP?) scsi blk-mq problem on sparc64
Date: Thu, 29 Jan 2015 16:37:51 +0000 [thread overview]
Message-ID: <54CA61DF.30807@kernel.dk> (raw)
In-Reply-To: <alpine.LRH.2.11.1501290952340.25245@math.ut.ee>
[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]
On 01/28/2015 11:53 PM, Meelis Roos wrote:
> On Mon, 24 Nov 2014, David Miller wrote:
>
>> From: mroos@linux.ee
>> Date: Tue, 25 Nov 2014 00:23:20 +0200 (EET)
>>
>>>>>>> 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.
>>>>>
>>>>> Hear, hear!!! That would make my life easier, and would make this sort
>>>>> of problem much less likely to occur!
>>>>
>>>> How about this one?
>>>
>>> It make the machine work.
>>
>> Thanks for testing!
>>
>
> What's the status of this fix? It is still not applied on yesterdays
> 3.19.0-rc6-00105-gc59c961 git...
Hmm, I thought commit a33c1ba29138 took care of it... Does the attached
work?
--
Jens Axboe
[-- Attachment #2: map-sz.patch --]
[-- Type: text/x-patch, Size: 644 bytes --]
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 5f13f4d0bcce..527d315dc1a5 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -88,10 +88,11 @@ 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 *map;
+ size_t sz;
/* If cpus are offline, map them to first hctx */
- map = kzalloc_node(sizeof(*map) * nr_cpu_ids, GFP_KERNEL,
- set->numa_node);
+ sz = max_t(unsigned int, nr_cpu_ids, num_possible_cpus());
+ map = kzalloc_node(sizeof(*map) * sz, GFP_KERNEL, set->numa_node);
if (!map)
return NULL;
next prev parent reply other threads:[~2015-01-29 16:38 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
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 [this message]
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=54CA61DF.30807@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.