All of lore.kernel.org
 help / color / mirror / Atom feed
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 09:31:29 -0800	[thread overview]
Message-ID: <20141124173129.GL5050@linux.vnet.ibm.com> (raw)
In-Reply-To: <547367DF.5060706@kernel.dk>

On Mon, Nov 24, 2014 at 10:16:15AM -0700, Jens Axboe wrote:
> On 11/24/2014 09:22 AM, Paul E. McKenney wrote:
> >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!
> 
> How about this one?

Works for me!

(Just for the record, as far as I know, this doesn't matter for RCU,
which already uses nr_cpu_ids.)

							Thanx, Paul

> -- 
> Jens Axboe
> 

> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
> index 0a9a6da21e74..db21f68aaef0 100644
> --- a/include/linux/cpumask.h
> +++ b/include/linux/cpumask.h
> @@ -83,7 +83,13 @@ extern const struct cpumask *const cpu_active_mask;
> 
>  #if NR_CPUS > 1
>  #define num_online_cpus()	cpumask_weight(cpu_online_mask)
> -#define num_possible_cpus()	cpumask_weight(cpu_possible_mask)
> +/*
> + * For platforms with discontig CPU numbering, the weight of the possible
> + * bitmask may be less than the highest numbered CPU. Return the max of
> + * the two, to prevent accidentical bugs.
> + */
> +#define num_possible_cpus()	\
> +	max_t(unsigned int, cpumask_weight(cpu_possible_mask), nr_cpu_ids)
>  #define num_present_cpus()	cpumask_weight(cpu_present_mask)
>  #define num_active_cpus()	cpumask_weight(cpu_active_mask)
>  #define cpu_online(cpu)		cpumask_test_cpu((cpu), cpu_online_mask)


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 17:31:29 +0000	[thread overview]
Message-ID: <20141124173129.GL5050@linux.vnet.ibm.com> (raw)
In-Reply-To: <547367DF.5060706@kernel.dk>

On Mon, Nov 24, 2014 at 10:16:15AM -0700, Jens Axboe wrote:
> On 11/24/2014 09:22 AM, Paul E. McKenney wrote:
> >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!
> 
> How about this one?

Works for me!

(Just for the record, as far as I know, this doesn't matter for RCU,
which already uses nr_cpu_ids.)

							Thanx, Paul

> -- 
> Jens Axboe
> 

> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
> index 0a9a6da21e74..db21f68aaef0 100644
> --- a/include/linux/cpumask.h
> +++ b/include/linux/cpumask.h
> @@ -83,7 +83,13 @@ extern const struct cpumask *const cpu_active_mask;
> 
>  #if NR_CPUS > 1
>  #define num_online_cpus()	cpumask_weight(cpu_online_mask)
> -#define num_possible_cpus()	cpumask_weight(cpu_possible_mask)
> +/*
> + * For platforms with discontig CPU numbering, the weight of the possible
> + * bitmask may be less than the highest numbered CPU. Return the max of
> + * the two, to prevent accidentical bugs.
> + */
> +#define num_possible_cpus()	\
> +	max_t(unsigned int, cpumask_weight(cpu_possible_mask), nr_cpu_ids)
>  #define num_present_cpus()	cpumask_weight(cpu_present_mask)
>  #define num_active_cpus()	cpumask_weight(cpu_active_mask)
>  #define cpu_online(cpu)		cpumask_test_cpu((cpu), cpu_online_mask)


  reply	other threads:[~2014-11-24 17:31 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 [this message]
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=20141124173129.GL5050@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.