Hi!
Looking at the topology_init() code, I observe that the meaning of
the cpuX/ directory entries in /sys/devices/system/cpu/ might be
different for different architectures.
Looks like, in case of i386, ia64, m32, mips etc, the cpuX directory entries
represent the "present cpus".
However, in case of powerpc, s390 etc, the cpuX entries represent the
"possible cpus".
Wondering if there is any particular reason for this discrepancy.
I am not entirely surely if it's due cpu hotplug because
both i386 and powerpc support it!
When I do a
"echo 1 > /sys/devices/system/cpu/cpuX/online" on a power box as root,
I might get "-bash: echo: write error: Invalid argument"
because cpuX might not be present!
In case of lpar, cpu_present_map need not necessarily be equal to
cpu_possible_map, so the above error is observable.
Is this discrepency intentional ?
Or is it due to the fact that in most cases,
cpu_present_map == cpu_possible_map, so lets not bother about it :-?
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
Hi Gautham-
Gautham R Shenoy wrote:
>
> Looking at the topology_init() code, I observe that the meaning of
> the cpuX/ directory entries in /sys/devices/system/cpu/ might be
> different for different architectures.
>
> Looks like, in case of i386, ia64, m32, mips etc, the cpuX directory entries
> represent the "present cpus".
>
> However, in case of powerpc, s390 etc, the cpuX entries represent the
> "possible cpus".
>
> Wondering if there is any particular reason for this discrepancy.
I believe that the powerpc behavior was established before
cpu_present_map was introduced.
> I am not entirely surely if it's due cpu hotplug because
> both i386 and powerpc support it!
powerpc also supports processor add and remove (as opposed to
online/offline); i386 does not AFAIK. I think this may be a reason
for the difference.
> When I do a
> "echo 1 > /sys/devices/system/cpu/cpuX/online" on a power box as root,
> I might get "-bash: echo: write error: Invalid argument"
> because cpuX might not be present!
>
> In case of lpar, cpu_present_map need not necessarily be equal to
> cpu_possible_map, so the above error is observable.
Working as intended. You have to add a cpu to the partition before
you can online it.
> Is this discrepency intentional ?
> Or is it due to the fact that in most cases,
> cpu_present_map == cpu_possible_map, so lets not bother about it :-?
I think it's the inevitable result when architectures are free to
invent their own versions of the same sysfs interface. But is it
really causing a problem in this case?
On Wed, May 02, 2007 at 11:37:57AM -0500, Nathan Lynch wrote:
> Hi Gautham-
>
> I believe that the powerpc behavior was established before
> cpu_present_map was introduced.
Ok. I guess the same is the reason with a few other architectures like
s390.
>
>
> > I am not entirely surely if it's due cpu hotplug because
> > both i386 and powerpc support it!
>
> powerpc also supports processor add and remove (as opposed to
> online/offline); i386 does not AFAIK. I think this may be a reason
> for the difference.
>
Well, ACPI seems to be supporting it.
acpi_processor_hotadd_init() in drivers/acpi/processor_core.c appears
to be equivalent to pSeries_add_processor(), except that the former
creates the sysfs entries on a hot add, while the later just updates
the cpu_present map.
>
> > When I do a
> > "echo 1 > /sys/devices/system/cpu/cpuX/online" on a power box as root,
> > I might get "-bash: echo: write error: Invalid argument"
> > because cpuX might not be present!
> >
> > In case of lpar, cpu_present_map need not necessarily be equal to
> > cpu_possible_map, so the above error is observable.
>
> Working as intended. You have to add a cpu to the partition before
> you can online it.
>
>
> > Is this discrepency intentional ?
> > Or is it due to the fact that in most cases,
> > cpu_present_map == cpu_possible_map, so lets not bother about it :-?
>
> I think it's the inevitable result when architectures are free to
> invent their own versions of the same sysfs interface. But is it
> really causing a problem in this case?
>
No, it is not causing any problems :-)
I was just overwhelmed to see cpu0 to cpu77 in the sysfs entries on the
lpar which I was using. Looking at the kernel code, I figured out that
the MAX_CPUS for that lpar was 39 and each virtual cpu was probably
running 2 threads. That explained the 78 sysfs entries.
Thanks for the explaination anyway.
Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
On Thu, May 03, 2007 at 12:22:35AM +0530, Gautham R Shenoy wrote:
> On Wed, May 02, 2007 at 11:37:57AM -0500, Nathan Lynch wrote:
> > Hi Gautham-
> >
> > I believe that the powerpc behavior was established before
> > cpu_present_map was introduced.
>
> Ok. I guess the same is the reason with a few other architectures like
> s390.
No, the reason for s390 is that we don't get any notification if
a new cpu gets attached, if running under z/VM (a hypervisor).
But since the cpuX/online attribute must exist to bring a cpu
online, the idea was to create the directories for all possible
cpus and if somebody tries to online a cpu the code will scan
for present and unused cpus and uses the first one...
Kind of stupid, but works.