linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jmayo@nvidia.com (Jon Mayo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: report present cpus in /proc/cpuinfo
Date: Wed, 22 Jun 2011 13:54:40 -0700	[thread overview]
Message-ID: <4E025690.5090201@nvidia.com> (raw)
In-Reply-To: <20110622201928.GW23234@n2100.arm.linux.org.uk>

On 06/22/2011 01:19 PM, Russell King - ARM Linux wrote:
> On Wed, Jun 22, 2011 at 12:26:11PM -0700, Jon Mayo wrote:
>> On 06/22/2011 02:36 AM, Russell King - ARM Linux wrote:
>>> Think about it - if you have real hot-pluggable CPUs (servers do), do
>>> you _really_ want to try to bring online a possible CPU (iow, there's
>>> a socket on the board) but one which isn't present (iow, the socket is
>>> empty.)
>>>
>>> That's what the possible + !present case caters for.  Possible tells
>>> the kernel how many CPUs to allocate per-cpu data structures for.
>>> present tells it whether a CPU can be onlined or not.
>>>
>>
>> Yes, that's the difference between present and possible. I'm not
>> suggesting we report cpus that do not exist. I'm suggesting we report
>> cpus that are present, online or not.
>
> Which is _what_ we do.  The problem is that mach-tegra is causing
> the established well defined APIs to mean something else, and then
> you're complaining that those APIs don't mean what they were defined
> to be.
>

in arch/arm/kernel/setup.c :

#if defined(CONFIG_SMP)
         for_each_online_cpu(i) {

no, the arm kernel reports online cpus, not present cpus. I now agree 
that this is the correct behavior, and is consistent with all other 
platforms. but your responses about present versus possible don't match 
the code.

> You're really shooting yourself in the foot here, and at this point
> there is nothing left to discuss.
>
> I can't help you.  You need to discuss this with folk who look after
> the hotplug CPU stuff.
>
> You no longer have an ARM architecture problem, your problem is that
> you're abusing stuff to get what you want and then complaining that
> stuff doesn't work as you want it.

I'm not complaining, I was seeking advice on the right way to do things. 
You've given me advice. Thank You. End-of-thread.

  reply	other threads:[~2011-06-22 20:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-21 22:56 [PATCH] ARM: report present cpus in /proc/cpuinfo Jon Mayo
2011-06-21 22:59 ` Fabio Estevam
2011-06-21 23:05 ` Russell King - ARM Linux
2011-06-21 23:24   ` Jon Mayo
2011-06-21 23:36     ` Russell King - ARM Linux
2011-06-22  0:08       ` Jon Mayo
2011-06-22  9:36         ` Russell King - ARM Linux
2011-06-22 19:26           ` Jon Mayo
2011-06-22 20:19             ` Russell King - ARM Linux
2011-06-22 20:54               ` Jon Mayo [this message]
2011-06-22 20:57                 ` Russell King - ARM Linux

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=4E025690.5090201@nvidia.com \
    --to=jmayo@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).