On 14.03.22 22:13, Bezdeka, Florian via Xenomai wrote:
> On Mon, 2022-03-14 at 21:05 +, Bezdeka, Florian via Xenomai wrote:
>> Hi Richard,
>>
>> On Mon, 2022-03-14 at 21:38 +0100, Richard Weinberger via Xenomai
>> wrote:
>>> BITS_PER_LONG is too broad, the max number of usable bits is limited
>
- Ursprüngliche Mail -
> Von: "Florian Bezdeka"
>> Where do you see a problem?
>
> I'm fine with the implementation. Just struggled with the wording /
> commit message. Sorry for the race in the mail thread...
No need to worry. :-)
Thanks,
//richard
On Mon, 2022-03-14 at 22:10 +0100, Richard Weinberger wrote:
> - Ursprüngliche Mail -
> > Von: "Florian Bezdeka"
> > I agree, BITS_PER_LONG seems wrong. But couldn't it be too small as
> > well? It depends on NR_CPUS which might be > BITS_PER_LONG.
>
> Hmm, nr_cpumask_bits is defined as:
On Mon, 2022-03-14 at 21:05 +, Bezdeka, Florian via Xenomai wrote:
> Hi Richard,
>
> On Mon, 2022-03-14 at 21:38 +0100, Richard Weinberger via Xenomai
> wrote:
> > BITS_PER_LONG is too broad, the max number of usable bits is limited
> > by nr_cpumask_bits.
>
> I agree, BITS_PER_LONG seems wro
- Ursprüngliche Mail -
> Von: "Florian Bezdeka"
> I agree, BITS_PER_LONG seems wrong. But couldn't it be too small as
> well? It depends on NR_CPUS which might be > BITS_PER_LONG.
Hmm, nr_cpumask_bits is defined as:
#ifdef CONFIG_CPUMASK_OFFSTACK
/* Assuming NR_CPUS is huge, a runtime li
Hi Richard,
On Mon, 2022-03-14 at 21:38 +0100, Richard Weinberger via Xenomai
wrote:
> BITS_PER_LONG is too broad, the max number of usable bits is limited
> by nr_cpumask_bits.
I agree, BITS_PER_LONG seems wrong. But couldn't it be too small as
well? It depends on NR_CPUS which might be > BITS_P
BITS_PER_LONG is too broad, the max number of usable bits is limited
by nr_cpumask_bits.
Found while debugging a system with CONFIG_DEBUG_PER_CPU_MAPS enabled.
Signed-off-by: Richard Weinberger
---
kernel/cobalt/sched.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kern
