From: Hugh Dickins <hugh@veritas.com>
To: "Brown, Len" <len.brown@intel.com>
Cc: "Grover, Andrew" <andrew.grover@intel.com>,
"'ACPI-Devel mailing list'" <acpi-devel@lists.sourceforge.net>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
"'Marcelo Tosatti'" <marcelo@conectiva.com.br>
Subject: Re: "noht" (RE: ACPI patches updated (20030714))
Date: Fri, 18 Jul 2003 06:04:17 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.44.0307180551060.1319-100000@localhost.localdomain> (raw)
In-Reply-To: <A5974D8E5F98D511BB910002A50A66470B981269@hdsmsx103.hd.intel.com>
On Thu, 17 Jul 2003, Brown, Len wrote:
> "noht" turns out to be tricky for ACPI in practice.
Thanks a lot for looking into it, Len.
Nice to know I wasn't being too silly when I said it's beyond me now.
> ACPI really shouldn't tinker with or skip LAPIC enumeration. It can't rely
> on the table LAPIC ids to get packge numbers, and it can't rely on the BIOS
> to have MPS implemented to enumerate physical processors.
>
> The only reliable way to get the logical/physical mapping is the way
> init_intel() does it today -- run CPUID locally on that logical processor
> after it is up and running.
>
> So if the kernel is to disable HT, the proper way would be to initialize all
> the logical processors, have them identify themselves, and then optionally
> take themselves off-line. A possiblity for 2.6.
Yes, a possibility. But I doubt it'll be worth bothering.
> BIOS SETUP remains the preferred way to disable HT. If the hardware is
> implemented such that duplicated resources could be combined when HT is
> disabled, only the BIOS would be able to do that -- so single threaded
> performance with Linux implemented 'noht' might lag performance with BIOS
> implemented 'noht'...
>
> Given that 'noht' is workaround for a missing BIOS switch, I'm not confident
> it is a win to burden the Linux kernel with it.
I imagine we could still retain it when going the acpitable.c route;
but I'd prefer to be consistent across the ways, and just remove all
traces of "noht" now (a boot option to mask off the "ht" flag from
cpuinfo, its current role, is definitely not worth retaining).
Hugh
prev parent reply other threads:[~2003-07-18 4:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-18 2:14 "noht" (RE: ACPI patches updated (20030714)) Brown, Len
2003-07-18 5:04 ` Hugh Dickins [this message]
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=Pine.LNX.4.44.0307180551060.1319-100000@localhost.localdomain \
--to=hugh@veritas.com \
--cc=acpi-devel@lists.sourceforge.net \
--cc=andrew.grover@intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/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;
as well as URLs for NNTP newsgroup(s).