Re: /sys/devices/system/cpu/*: Present cpus or Possible cpus
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /sys/devices/system/cpu/*: Present cpus or Possible cpus
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /sys/devices/system/cpu/*: Present cpus or Possible cpus
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!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /sys/devices/system/cpu/*: Present cpus or Possible cpus
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /sys/devices/system/cpu/*: Present cpus or Possible cpus
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /sys/devices/system/cpu/*: Present cpus or Possible cpus
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! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
