From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@infradead.org>,
David Miller <davem@davemloft.net>,
mroos@linux.ee, linux-scsi@vger.kernel.org,
sparclinux@vger.kernel.org
Subject: Re: Another (ESP?) scsi blk-mq problem on sparc64
Date: Mon, 24 Nov 2014 08:22:49 -0800 [thread overview]
Message-ID: <20141124162249.GG5050@linux.vnet.ibm.com> (raw)
In-Reply-To: <54735052.7020807@kernel.dk>
On Mon, Nov 24, 2014 at 08:35:46AM -0700, Jens Axboe wrote:
> 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.
Hear, hear!!! That would make my life easier, and would make this sort
of problem much less likely to occur!
Thanx, Paul
> /* 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
>
> 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: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@infradead.org>,
David Miller <davem@davemloft.net>,
mroos@linux.ee, linux-scsi@vger.kernel.org,
sparclinux@vger.kernel.org
Subject: Re: Another (ESP?) scsi blk-mq problem on sparc64
Date: Mon, 24 Nov 2014 16:22:49 +0000 [thread overview]
Message-ID: <20141124162249.GG5050@linux.vnet.ibm.com> (raw)
In-Reply-To: <54735052.7020807@kernel.dk>
On Mon, Nov 24, 2014 at 08:35:46AM -0700, Jens Axboe wrote:
> 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.
Hear, hear!!! That would make my life easier, and would make this sort
of problem much less likely to occur!
Thanx, Paul
> /* 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
>
> 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 16:22 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 [this message]
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=20141124162249.GG5050@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=axboe@kernel.dk \
--cc=davem@davemloft.net \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mroos@linux.ee \
--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.