[cgl_discussion] CONFIG_HYPERTHREADING ??
sunil.saxena at intel.com
Tue Oct 8 09:33:36 PDT 2002
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.
2. ISVs should not be charging per logical CPU. The information for logical
and physical CPU is all available in /proc/cpuinfo.
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.
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.
cgl_discussion mailing list
cgl_discussion at lists.osdl.org
More information about the cgl_discussion