On 11/24/2014 02:56 PM, David Miller wrote:
From: Jens Axboe <axboe@xxxxxxxxx>
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() count
from a different perspective is really confusing.
Not disagreeing with you... Personally I don't care too much, I can just
work-around this in blk-mq. I'm more worried about others reimplementing
the same bugs later. And yes, the fact that's it's the weight of the
bitmap is exactly the problem, as we have no good way of saying
"allocate me this array indexed by cpu count", since we don't know the
numbers of the CPUs. This isn't a problem on x86 (or on anything but
sparc64, as far as I'm aware), since the weight and highest CPU count
are one and the same.
Usually when people want a per-cpu thing they allocate percpu
memory which hides all of these details, why don't you allocate
the map as dynamic per-cpu memory?
It will also do the NUMA node local allocations for you as well.
The allocation is node affine currently. This isn't per-cpu storage, for
the per-cpu storage blk-mq uses the normal per-cpu primitives for
alloctions. It's just a small array mapping a cpu number to a hardware
queue number. It's read-only storage, after it has been updated.
I'll just updated blk-mq to use nr_cpu_ids and be done with it.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
