From: Mikael Pettersson <mikpe@csd.uu.se>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: "Mikael Pettersson" <mikpe@csd.uu.se>, <jamesclv@us.ibm.com>,
"Jason Lunz" <lunz@falooley.org>, <linux-kernel@vger.kernel.org>
Subject: RE: detecting hyperthreading in linux 2.4.19
Date: Fri, 10 Jan 2003 09:43:51 +0100 [thread overview]
Message-ID: <15902.34759.187965.633490@harpo.it.uu.se> (raw)
In-Reply-To: <C8C38546F90ABF408A5961FC01FDBF1912E20B@fmsmsx405.fm.intel.com>
Pallipadi, Venkatesh writes:
>
> > -----Original Message-----
> > From: Mikael Pettersson [mailto:mikpe@csd.uu.se]
> >
> > My performance monitoring counters driver uses this approach
> > in kernel-space
> > using smp_call_function(). I don't use the siblings tables
> > because they suck :-)
> > [I don't think they distinguish between logical CPUs #0 and
> > #1, and they aren't
> > exported to modules. The CPUID check is simple and portable
> > across kernel versions.]
>
> I believe it is better to use a OS interface to find out HT, rather than
> using CPUID. The reason being, it is possible to have HT disabled, in OS,
> even after processor and the BIOS supports it.
> 1) Consider the case when processor and BIOS supports HT, but linux
> was booted with "noht" boot option (now I am not sure whether that option is
> there in 2.4.19. But is is certainly there in some other kernels).
> 2) What about some other kernel which is totally ignorant about HT, and
> doesn't initialize logical processor (kernel which looks at MPS in place
> of ACPI)
> I think, in both these cases cpuid can still say HT is present.
With smp_call_function() I execute code on exactly those CPUs the kernel
knows about. If the physical processors support HT but the kernel can't
run on the non-#0 logical CPUs (UP kernel or "noht"), then smp_call_function()
won't reach those logical CPUs #1 and everything's fine: my test will say
"not HT" which is exactly what I want in this case.
The point about checking the "local APIC physical ID" in CPUID 1, EBX,
instead of the field in the local APIC is _exactly_ because the CPUID
data is assigned by HW and read-only, while the local APIC field can be
changed. I don't want to depend on possibly-broken MP or ACPI tables or
have to know about the kernel's physical <--> virtual CPU # mapping de jour.
> I know that sibling table is not exported. But I couldn't get your other
> comment about sibling table "they distinguish between logical CPUs #0 and #1:"
> Can you elaborate..
The sibling table tells you whether two linux-numbered CPUs are siblings,
but it doesn't tell which one is logical CPU #0 and which one is #1.
That distinction is important in some cases.
next prev parent reply other threads:[~2003-01-10 8:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-10 8:16 Pallipadi, Venkatesh
2003-01-10 8:43 ` Mikael Pettersson [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-01-09 23:26 Pallipadi, Venkatesh
2003-01-09 22:29 Kamble, Nitin A
2003-01-09 20:02 Jason Lunz
2003-01-09 21:37 ` James Cleverdon
2003-01-09 21:54 ` John Bradford
2003-01-10 0:16 ` James Cleverdon
2003-01-10 0:58 ` Mike Dresser
2003-01-09 21:57 ` Jason Lunz
2003-01-10 12:29 ` Mark Hounschell
2003-01-10 7:05 ` Mikael Pettersson
2003-01-10 11:05 ` Dave Jones
2003-01-10 11:19 ` Mikael Pettersson
2003-01-10 0:20 ` Dave Jones
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=15902.34759.187965.633490@harpo.it.uu.se \
--to=mikpe@csd.uu.se \
--cc=jamesclv@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lunz@falooley.org \
--cc=venkatesh.pallipadi@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®