[cgl_discussion] CONFIG_HYPERTHREADING ??

[Saxena, Sunil]

Hi Randy,

Like to know the ISVs that are charging per logical CPU.  Intel went in
great length working with the ISVs to make sure they will charge per
physical CPU.  I believe that is the way ISVs for Windows handle.  I hope
Linux ISVs understand that as well.  There is lot of information on this
technology on developer.intel.com.  Just search for hyperthreading.

Thanks
Sunil


-----Original Message-----
From: Randy.Dunlap [mailto:rddunlap at osdl.org] 
Sent: Tuesday, October 08, 2002 9:43 AM
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