* [PATCH] cobalt/sched: Use nr_cpumask_bits instead of BITS_PER_LONG
@ 2022-03-14 20:38 Richard Weinberger
2022-03-14 21:05 ` Bezdeka, Florian
0 siblings, 1 reply; 7+ messages in thread
From: Richard Weinberger @ 2022-03-14 20:38 UTC (permalink / raw)
To: xenomai; +Cc: Richard Weinberger
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 <richard@nod.at>
---
kernel/cobalt/sched.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/cobalt/sched.c b/kernel/cobalt/sched.c
index 88c4951ed814..aa65fd7f5d63 100644
--- a/kernel/cobalt/sched.c
+++ b/kernel/cobalt/sched.c
@@ -1370,7 +1370,7 @@ static int affinity_vfile_show(struct xnvfile_regular_iterator *it,
unsigned long val = 0;
int cpu;
- for (cpu = 0; cpu < BITS_PER_LONG; cpu++)
+ for (cpu = 0; cpu < nr_cpumask_bits; cpu++)
if (cpumask_test_cpu(cpu, &cobalt_cpu_affinity))
val |= (1UL << cpu);
@@ -1395,7 +1395,7 @@ static ssize_t affinity_vfile_store(struct xnvfile_input *input)
affinity = xnsched_realtime_cpus; /* Reset to default. */
else {
cpumask_clear(&affinity);
- for (cpu = 0; cpu < BITS_PER_LONG; cpu++, val >>= 1) {
+ for (cpu = 0; cpu < nr_cpumask_bits; cpu++, val >>= 1) {
if (val & 1) {
/*
* The new dynamic affinity must be a strict
--
2.26.2
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] cobalt/sched: Use nr_cpumask_bits instead of BITS_PER_LONG
2022-03-14 20:38 [PATCH] cobalt/sched: Use nr_cpumask_bits instead of BITS_PER_LONG Richard Weinberger
@ 2022-03-14 21:05 ` Bezdeka, Florian
2022-03-14 21:10 ` Richard Weinberger
2022-03-14 21:13 ` Bezdeka, Florian
0 siblings, 2 replies; 7+ messages in thread
From: Bezdeka, Florian @ 2022-03-14 21:05 UTC (permalink / raw)
To: xenomai, richard
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_PER_LONG.
Regards,
Florian
> Found while debugging a system with CONFIG_DEBUG_PER_CPU_MAPS enabled.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
> kernel/cobalt/sched.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/cobalt/sched.c b/kernel/cobalt/sched.c
> index 88c4951ed814..aa65fd7f5d63 100644
> --- a/kernel/cobalt/sched.c
> +++ b/kernel/cobalt/sched.c
> @@ -1370,7 +1370,7 @@ static int affinity_vfile_show(struct xnvfile_regular_iterator *it,
> unsigned long val = 0;
> int cpu;
>
> - for (cpu = 0; cpu < BITS_PER_LONG; cpu++)
> + for (cpu = 0; cpu < nr_cpumask_bits; cpu++)
> if (cpumask_test_cpu(cpu, &cobalt_cpu_affinity))
> val |= (1UL << cpu);
>
> @@ -1395,7 +1395,7 @@ static ssize_t affinity_vfile_store(struct xnvfile_input *input)
> affinity = xnsched_realtime_cpus; /* Reset to default. */
> else {
> cpumask_clear(&affinity);
> - for (cpu = 0; cpu < BITS_PER_LONG; cpu++, val >>= 1) {
> + for (cpu = 0; cpu < nr_cpumask_bits; cpu++, val >>= 1) {
> if (val & 1) {
> /*
> * The new dynamic affinity must be a strict
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] cobalt/sched: Use nr_cpumask_bits instead of BITS_PER_LONG
2022-03-14 21:05 ` Bezdeka, Florian
@ 2022-03-14 21:10 ` Richard Weinberger
2022-03-14 21:15 ` Bezdeka, Florian
2022-03-14 21:13 ` Bezdeka, Florian
1 sibling, 1 reply; 7+ messages in thread
From: Richard Weinberger @ 2022-03-14 21:10 UTC (permalink / raw)
To: Florian Bezdeka; +Cc: xenomai
----- Ursprüngliche Mail -----
> Von: "Florian Bezdeka" <florian.bezdeka@siemens.com>
> 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 limit is more efficient. Also,
* not all bits may be allocated. */
#define nr_cpumask_bits nr_cpu_ids
#else
#define nr_cpumask_bits ((unsigned int)NR_CPUS)
#endif
Where do you see a problem?
Thanks,
//richard
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] cobalt/sched: Use nr_cpumask_bits instead of BITS_PER_LONG
2022-03-14 21:05 ` Bezdeka, Florian
2022-03-14 21:10 ` Richard Weinberger
@ 2022-03-14 21:13 ` Bezdeka, Florian
2022-03-15 6:35 ` Jan Kiszka
1 sibling, 1 reply; 7+ messages in thread
From: Bezdeka, Florian @ 2022-03-14 21:13 UTC (permalink / raw)
To: xenomai, richard
On Mon, 2022-03-14 at 21:05 +0000, 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 wrong. But couldn't it be too small as
> well? It depends on NR_CPUS which might be > BITS_PER_LONG.
Sorry that was unclear. I assume that the size of the cpumask depends
somehow on NR_CPUS, which might be > BITS_PER_LONG. So BITS_PER_LONG
might be too small AND might be too broad.
>
> Regards,
> Florian
>
> > Found while debugging a system with CONFIG_DEBUG_PER_CPU_MAPS enabled.
> >
> > Signed-off-by: Richard Weinberger <richard@nod.at>
> > ---
> > kernel/cobalt/sched.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/cobalt/sched.c b/kernel/cobalt/sched.c
> > index 88c4951ed814..aa65fd7f5d63 100644
> > --- a/kernel/cobalt/sched.c
> > +++ b/kernel/cobalt/sched.c
> > @@ -1370,7 +1370,7 @@ static int affinity_vfile_show(struct xnvfile_regular_iterator *it,
> > unsigned long val = 0;
> > int cpu;
> >
> > - for (cpu = 0; cpu < BITS_PER_LONG; cpu++)
> > + for (cpu = 0; cpu < nr_cpumask_bits; cpu++)
> > if (cpumask_test_cpu(cpu, &cobalt_cpu_affinity))
> > val |= (1UL << cpu);
> >
> > @@ -1395,7 +1395,7 @@ static ssize_t affinity_vfile_store(struct xnvfile_input *input)
> > affinity = xnsched_realtime_cpus; /* Reset to default. */
> > else {
> > cpumask_clear(&affinity);
> > - for (cpu = 0; cpu < BITS_PER_LONG; cpu++, val >>= 1) {
> > + for (cpu = 0; cpu < nr_cpumask_bits; cpu++, val >>= 1) {
> > if (val & 1) {
> > /*
> > * The new dynamic affinity must be a strict
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] cobalt/sched: Use nr_cpumask_bits instead of BITS_PER_LONG
2022-03-14 21:10 ` Richard Weinberger
@ 2022-03-14 21:15 ` Bezdeka, Florian
2022-03-14 21:25 ` Richard Weinberger
0 siblings, 1 reply; 7+ messages in thread
From: Bezdeka, Florian @ 2022-03-14 21:15 UTC (permalink / raw)
To: richard; +Cc: xenomai
On Mon, 2022-03-14 at 22:10 +0100, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
> > Von: "Florian Bezdeka" <florian.bezdeka@siemens.com>
> > 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 limit is more efficient. Also,
> * not all bits may be allocated. */
> #define nr_cpumask_bits nr_cpu_ids
> #else
> #define nr_cpumask_bits ((unsigned int)NR_CPUS)
> #endif
>
> 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...
>
> Thanks,
> //richard
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] cobalt/sched: Use nr_cpumask_bits instead of BITS_PER_LONG
2022-03-14 21:15 ` Bezdeka, Florian
@ 2022-03-14 21:25 ` Richard Weinberger
0 siblings, 0 replies; 7+ messages in thread
From: Richard Weinberger @ 2022-03-14 21:25 UTC (permalink / raw)
To: Florian Bezdeka; +Cc: xenomai
----- Ursprüngliche Mail -----
> Von: "Florian Bezdeka" <florian.bezdeka@siemens.com>
>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] cobalt/sched: Use nr_cpumask_bits instead of BITS_PER_LONG
2022-03-14 21:13 ` Bezdeka, Florian
@ 2022-03-15 6:35 ` Jan Kiszka
0 siblings, 0 replies; 7+ messages in thread
From: Jan Kiszka @ 2022-03-15 6:35 UTC (permalink / raw)
To: Bezdeka, Florian, xenomai, richard
On 14.03.22 22:13, Bezdeka, Florian via Xenomai wrote:
> On Mon, 2022-03-14 at 21:05 +0000, 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 wrong. But couldn't it be too small as
>> well? It depends on NR_CPUS which might be > BITS_PER_LONG.
>
> Sorry that was unclear. I assume that the size of the cpumask depends
> somehow on NR_CPUS, which might be > BITS_PER_LONG. So BITS_PER_LONG
> might be too small AND might be too broad.
>
Good hint, I've adjusted this on merge.
Thanks,
Jan
>>
>> Regards,
>> Florian
>>
>>> Found while debugging a system with CONFIG_DEBUG_PER_CPU_MAPS enabled.
>>>
>>> Signed-off-by: Richard Weinberger <richard@nod.at>
>>> ---
>>> kernel/cobalt/sched.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/cobalt/sched.c b/kernel/cobalt/sched.c
>>> index 88c4951ed814..aa65fd7f5d63 100644
>>> --- a/kernel/cobalt/sched.c
>>> +++ b/kernel/cobalt/sched.c
>>> @@ -1370,7 +1370,7 @@ static int affinity_vfile_show(struct xnvfile_regular_iterator *it,
>>> unsigned long val = 0;
>>> int cpu;
>>>
>>> - for (cpu = 0; cpu < BITS_PER_LONG; cpu++)
>>> + for (cpu = 0; cpu < nr_cpumask_bits; cpu++)
>>> if (cpumask_test_cpu(cpu, &cobalt_cpu_affinity))
>>> val |= (1UL << cpu);
>>>
>>> @@ -1395,7 +1395,7 @@ static ssize_t affinity_vfile_store(struct xnvfile_input *input)
>>> affinity = xnsched_realtime_cpus; /* Reset to default. */
>>> else {
>>> cpumask_clear(&affinity);
>>> - for (cpu = 0; cpu < BITS_PER_LONG; cpu++, val >>= 1) {
>>> + for (cpu = 0; cpu < nr_cpumask_bits; cpu++, val >>= 1) {
>>> if (val & 1) {
>>> /*
>>> * The new dynamic affinity must be a strict
>>
>
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-03-15 6:35 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-14 20:38 [PATCH] cobalt/sched: Use nr_cpumask_bits instead of BITS_PER_LONG Richard Weinberger
2022-03-14 21:05 ` Bezdeka, Florian
2022-03-14 21:10 ` Richard Weinberger
2022-03-14 21:15 ` Bezdeka, Florian
2022-03-14 21:25 ` Richard Weinberger
2022-03-14 21:13 ` Bezdeka, Florian
2022-03-15 6:35 ` Jan Kiszka
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.