Re: [PATCH] x86, apic: Do not increment disabled_cpus from generic_processor_info.

[Rakib Mullick]

On Mon, Jan 10, 2011 at 3:57 PM, Cyrill Gorcunov <gorcunov@xxxxxxxxx> wrote:
> On 01/10/2011 07:06 AM, Rakib Mullick wrote:
>> On Mon, Jan 10, 2011 at 12:38 AM, Cyrill Gorcunov <gorcunov@xxxxxxxxx> wrote:
>>>
>> When we use nr_cpus=n, it works as an upper limit. If there are any
>> other CPUs beyond that limit those are not counted and we couldn't put
>> them back on work. So, when we couldn't use hotpluging feature to back
>> them into work, should we care about them?
>>
>
>  Yes we should, the cpus which are present but offlined (due to maxcpus
> or whatever reason) are listed in sysfs so i fear such a change would
> break compatibility with userspace as well.
>
For an example, there are 4 CPUs, we did nr_cpus=2 at boot time. Then
using hotpluging feature we can put CPUs online or offline only these
two CPUs, not the 3rd or 4th CPUs that we left out at startup. But, by
incrementing disabled_cpus at generic_processor_info we are accouting
those two left out CPUs. And latter on at cpumask build up (in
smpboot.c) we're using disabled_cpus to build cpumask bit.

So, as you are fearing about sysfs listing, those maybe right but only
for CPUs we have by passing nr_cpus.

>  Rakib, don't get me wrong, I don't like to complain but the side effect
> of the patch might be pretty inconvenient.
>
It's okay. My primary intention was to raise the issue and have some
disscussion about it. Not necessarily, it must have to included. And
it also helps to clear up the concept and that is why was expecting
Ingo's opinion.


thanks,
rakib

> --
>    Cyrill
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/