From: Michael Neuling <mikey@neuling.org>
To: Joel Schopp <jschopp@austin.ibm.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] powerpc: update ibm,client-architecture
Date: Tue, 22 Dec 2009 11:33:16 +1100 [thread overview]
Message-ID: <16243.1261441996@neuling.org> (raw)
In-Reply-To: <4B2FF35E.9020101@austin.ibm.com>
>>> OK.
>>>
>>>>> + W(NR_CPUS/4), /* max cores supported */
>>>>>
>>
>> FYI reading the PAPR, this comment should technically be "max 'cpu'
>> nodes presented".
>>
>I applied a disambiguation filter to the comment since cpus can mean a
>lot of things these days ( ie hardware threads, cores, chips) , but a
>core is a core.
I think you applied ambiguation filter actually :-)
The PAPR is clear and perfectly understandable in this context. It's
"OF device tree nodes of type 'cpu'".
>>> 4 is the new 2.
>>>
>>
>> I'd still be asking what 2 is. It's needs a #define to make clearer
>> what you are doing.
>>
>>
>I'll add a #define
>>> Since you don't know the actual threads per core at
>>> this point in boot you have to be conservative and go with the maximum
>>> number of any processor. See page 4 of these charts:
>>> http://www.power.org/events/powercon09/taiwan09/IBM_Overview_POWER7.pdf
>>>
>>
>> I don't think hard wiring 4 in here is right. If we are booting a
>> machine with SMT2, we will put only half the number of cores that we can
>> handle in this field. This is going to break a lot of machines where
>> people have compiled with NR_CPUS = thread number.
>>
>> I think you just want to put NR_CPUS here.
>>
>>
>It's a bad interface. No matter what you choose there will be a
>downside. 1) If you choose NR_CPUS, the best case of how many you could
>boot without SMT, then when you boot with SMT2 or SMT4 you can get
>assigned more cpus than you can boot. 2) If you choose NR_CPUS/4, the
>worst case of how many you could boot, and you get a large machine with
>SMT2 or SMT1 you might have said you support less cpus than you actually
>do and thus not boot all the cpus. So no matter what you choose you
>could be not booting cpus in some theoretical scenario.
Sure but 1) is how Linux behaves now (we can always get more cpus than
we can handle) and 2) is what you are changing it to. 2) is going to
break existing users.
Anyway, if you are intending to change functionality like this, please
make it clear in the check in comment.
Mikey
next prev parent reply other threads:[~2009-12-22 0:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-18 21:07 [PATCH] powerpc: update ibm,client-architecture Joel Schopp
2009-12-20 23:59 ` Michael Neuling
2009-12-21 18:15 ` Joel Schopp
2009-12-21 21:12 ` Michael Neuling
2009-12-21 22:14 ` Joel Schopp
2009-12-22 0:33 ` Michael Neuling [this message]
2009-12-22 0:58 ` Tony Breeds
2009-12-21 0:44 ` Tony Breeds
2009-12-21 18:22 ` Joel Schopp
2009-12-22 0:18 ` Tony Breeds
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=16243.1261441996@neuling.org \
--to=mikey@neuling.org \
--cc=jschopp@austin.ibm.com \
--cc=linuxppc-dev@ozlabs.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 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.