[cgl_discussion] CONFIG_HYPERTHREADING ??

[John Grana]

Is Hyperthreading something that only applies to x86 architecture?
If not, then having the ability to disable via BIOS is ok, but other
processor architectures such as Sparc (with OpenBoot), MIPS, PowerPC etc.
have different ideas of BIOS (like boot proms, monitors, etc.). So, the way
it was descibed below:

"We did not make a statement specific to HOW to make this (or in general all
of the)requirement(s) actually configurable"

Is the best road IMHO.

Cheers
John Grana




-----Original Message-----
From: cgl_discussion-admin at lists.osdl.org
[mailto:cgl_discussion-admin at lists.osdl.org]On Behalf Of Randy.Dunlap
Sent: Tuesday, October 08, 2002 12:43 PM
To: Saxena, Sunil
Cc: 'Mika Kukkonen'; Peter Badovinatz; cgl_discussion at osdl.org
Subject: RE: [cgl_discussion] CONFIG_HYPERTHREADING ??


On Tue, 8 Oct 2002, Saxena, Sunil wrote:

| I like to add couple of points for everyone's information:
|
| 1. Distributors are shipping their distribution with HT enabled by
default.
| Intel's recommended way of turning of HT is to do it via the BIOS.

I have no problem using BIOS to disable HT instead of a kernel
CONFIG_HT option.

| 2. ISVs should not be charging per logical CPU.  The information for
logical
| and physical CPU is all available in /proc/cpuinfo.

We can't control ISVs.
BTW, what is MS doing with it regarding multi-proc charges?

Of course, this CGL requirement (for disabling HT) came up because
someone apparently is charging for logical CPUs, and customers
don't want to pay for it with such performance gains (below).

| 3. We are seeing 10-35% performance benefit for HT with different
workloads.
| Like to hear on cases where one does not see any benefit.

Send such systems this way and I'll let you know.  :)

~Randy

| Thanks
| Sunil
|
|
| -----Original Message-----
| From: Mika Kukkonen [mailto:mika at osdl.org]
| Sent: Tuesday, October 08, 2002 6:59 AM
| To: Peter Badovinatz
| Cc: cgl_discussion at osdl.org
| Subject: Re: [cgl_discussion] CONFIG_HYPERTHREADING ??
|
|
| On ma, 2002-10-07 at 18:40, Peter Badovinatz wrote:
| (...)
| > Correct, the decision was to make it configurable.  We did not make a
| > statement specific to HOW to make this (or in general all of the)
| > requirement(s) actually configurable, although the discussion for this
| > one strongly implied that it would be able to be removed to the point of
| > not being available.  To follow the license issue, a vendor may want it
| > absolutely unavailable (i.e., compiled out) to prevent usage (accidental
| > or otherwise) if it were boot time set.
| >
| > This issue in general would be another aspect necessary to be covered by
| > a certification suite, if we have configurable items what does that mean
| > and how do you certify them (or them not being there.)
|
| Like I replied to Craig, the certification is to be done with _every_
| feature turned on (and yes, this is going to make some distro vendors
| unhappy by forcing them to actually implement every feature in v.1);
| that was the decision made in Helsinki F2F as far as I recall.
|
| After the certification the distro vendor may choose to configure some
| features out (like hyperthreading in kernel config file) and recompile,
| but the distro vendor can not add or remove significant pieces of code
| without being forced to re-certify.
|
| > An interesting follow-on, IMHO most distros will only test a much more
| > limited range of permutations of core+configurable items.  Are we going
| > to claim that we've built and/or tested similarly, or simply pick some
| > few (or 1?) combinations and identify those?
|
| See my reply above.
|
| --MiKu

_______________________________________________
cgl_discussion mailing list
cgl_discussion at lists.osdl.org
http://lists.osdl.org/mailman/listinfo/cgl_discussion