From: Gautham R Shenoy <ego@in.ibm.com>
To: Nathan Lynch <ntl@pobox.com>
Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
ashok.raj@intel.com, heiko.carstens@de.ibm.com,
linux-kernel@vger.kernel.org
Subject: Re: /sys/devices/system/cpu/*: Present cpus or Possible cpus
Date: Thu, 3 May 2007 00:22:35 +0530 [thread overview]
Message-ID: <20070502185235.GA6859@in.ibm.com> (raw)
In-Reply-To: <20070502163757.GF30688@localdomain>
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!"
next prev parent reply other threads:[~2007-05-02 18:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-02 11:00 /sys/devices/system/cpu/*: Present cpus or Possible cpus Gautham R Shenoy
2007-05-02 16:37 ` Nathan Lynch
2007-05-02 18:52 ` Gautham R Shenoy [this message]
2007-05-03 13:42 ` Heiko Carstens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070502185235.GA6859@in.ibm.com \
--to=ego@in.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=ashok.raj@intel.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ntl@pobox.com \
--cc=vatsa@in.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.