> > > > > > > > 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
On 01/28/2015 11:53 PM, Meelis Roos wrote:
On Mon, 24 Nov 2014, David Miller wrote:
From: mr...@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
iteratin
On Mon, 24 Nov 2014, David Miller wrote:
> From: mr...@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 cp
From: mr...@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
>>
> > > > 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 tha
On 11/24/2014 03:09 PM, David Miller wrote:
From: Jens Axboe
Date: Mon, 24 Nov 2014 15:01:55 -0700
I'll just updated blk-mq to use nr_cpu_ids and be done with it.
Wow, a grep on nr_cpu_ids gets a lot of hits on people allocating just
these kinds of tables :)
Yep! It'd be nicer to export a
From: Jens Axboe
Date: Mon, 24 Nov 2014 15:01:55 -0700
> I'll just updated blk-mq to use nr_cpu_ids and be done with it.
Wow, a grep on nr_cpu_ids gets a lot of hits on people allocating just
these kinds of tables :)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the
On 11/24/2014 02:56 PM, David Miller wrote:
From: Jens Axboe
Date: Mon, 24 Nov 2014 10:16:15 -0700
How about this one?
The "num" in num_possible_cpus() means a count, as in how many are
there.
It doesn't mean largest ID of members of set X, which is what you
are asking for.
Even worse, hav
From: Jens Axboe
Date: Mon, 24 Nov 2014 10:16:15 -0700
> How about this one?
The "num" in num_possible_cpus() means a count, as in how many are
there.
It doesn't mean largest ID of members of set X, which is what you
are asking for.
Even worse, having num_online_cpus() and num_possible_cpus()
On Mon, Nov 24, 2014 at 10:33:37AM -0700, Jens Axboe wrote:
> On 11/24/2014 10:31 AM, Paul E. McKenney wrote:
> >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
On 11/24/2014 10:31 AM, Paul E. McKenney wrote:
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:5
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:
>
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
us
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
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 problem
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 Sp
From: Christoph Hellwig
Date: Wed, 19 Nov 2014 22:01:35 -0800
> On Sat, Nov 15, 2014 at 08:31:00AM -0700, Jens Axboe wrote:
>> My next move would be to add more debug to the CPU map setup and teardown,
>> so that we can verify that the map that is being used above has indeed been
>> setup. Unless
On Sat, Nov 15, 2014 at 08:31:00AM -0700, Jens Axboe wrote:
> My next move would be to add more debug to the CPU map setup and teardown,
> so that we can verify that the map that is being used above has indeed been
> setup. Unless Christoph has any ideas on what is going on here?
No good idea, but
On 2014-11-14 23:48, Meelis Roos wrote:
[ 247.424529] sd 0:0:2:0: [sdc] READ CAPACITY failed
[ 247.479803] sd 0:0:2:0: [sdc]
[ 247.517288] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 247.583978] sd 0:0:2:0: [sdc]
[ 247.621487] Sense Key : Not Ready [current]
[ 247.672493] sd 0:0:2:0:
> On 2014-11-14 15:59, Meelis Roos wrote:
> > > > > The second oops is in blk_mq_map_queue() which is a trivial
> > > > > two level cpu lookup. I wonder if there's something odd about
> > > > > cpu numbers on these big old sparc systems?
> > > >
> > > > CPU numbers are sparse - they are determined
On 2014-11-14 15:59, Meelis Roos wrote:
The second oops is in blk_mq_map_queue() which is a trivial
two level cpu lookup. I wonder if there's something odd about
cpu numbers on these big old sparc systems?
CPU numbers are sparse - they are determined by hardware slot number and
some models onl
> >> The second oops is in blk_mq_map_queue() which is a trivial
> >> two level cpu lookup. I wonder if there's something odd about
> >> cpu numbers on these big old sparc systems?
> >
> > CPU numbers are sparse - they are determined by hardware slot number and
> > some models only fill every ot
On 11/14/2014 12:35 PM, Meelis Roos wrote:
>> Paul, what's the best way to figure out these CPU stalls?
>>
>> The second oops is in blk_mq_map_queue() which is a trivial
>> two level cpu lookup. I wonder if there's something odd about
>> cpu numbers on these big old sparc systems?
>
> CPU numbers
> Paul, what's the best way to figure out these CPU stalls?
>
> The second oops is in blk_mq_map_queue() which is a trivial
> two level cpu lookup. I wonder if there's something odd about
> cpu numbers on these big old sparc systems?
CPU numbers are sparse - they are determined by hardware slot
On 11/14/2014 09:58 AM, Christoph Hellwig wrote:
> Paul, what's the best way to figure out these CPU stalls?
>
> The second oops is in blk_mq_map_queue() which is a trivial
> two level cpu lookup. I wonder if there's something odd about
> cpu numbers on these big old sparc systems?
>
> Something
Paul, what's the best way to figure out these CPU stalls?
The second oops is in blk_mq_map_queue() which is a trivial
two level cpu lookup. I wonder if there's something odd about
cpu numbers on these big old sparc systems?
Something like the debug patch below might shed some light on where the
26 matches
Mail list logo
