[cgl_discussion] CONFIG_HYPERTHREADING ??

Randy.Dunlap rddunlap at osdl.org
Tue Oct 8 10:03:31 PDT 2002


Sure, that's a reasonable request, and I can't answer it.
This CGL requirement was added because of it though, or perhaps
only because of fears of it.  I don't know if we have enough
recorded history for detailed background info about this.

~Randy

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

| 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




More information about the cgl_discussion mailing list