linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* "noht" (RE: ACPI patches updated (20030714))
@ 2003-07-18  2:14 Brown, Len
  2003-07-18  5:04 ` Hugh Dickins
  0 siblings, 1 reply; 2+ messages in thread
From: Brown, Len @ 2003-07-18  2:14 UTC (permalink / raw)
  To: 'Hugh Dickins'
  Cc: Grover, Andrew, 'ACPI-Devel mailing list',
	'linux-kernel@vger.kernel.org', 'Marcelo Tosatti'

"noht" turns out to be tricky for ACPI in practice.

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.

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.

Cheers,
-Len


> -----Original Message-----
> From: Brown, Len 
> Sent: Tuesday, July 15, 2003 10:36 PM
> To: 'Hugh Dickins'
> Cc: Grover, Andrew; ACPI-Devel mailing list; 
> linux-kernel@vger.kernel.org; Marcelo Tosatti
> Subject: RE: ACPI patches updated (20030714)
> 
> 
> > From: Hugh Dickins [mailto:hugh@veritas.com] 
> 
> > > 		ACPI && !ACPI_HT_ONLY
> > > 			Full ACPI w/o the acpi=cpu option
> > 
> > Shouldn't this combination also support "noht", or is that 
> > too much to ask?
> 
> Can do.  It will be called CONFIG_ACPI_HT, and will be 
> required for ACPI to enable HT -- with or without the full 
> CONFIG_ACPI.
> 
> Cheers,
> -Len
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: "noht" (RE: ACPI patches updated (20030714))
  2003-07-18  2:14 "noht" (RE: ACPI patches updated (20030714)) Brown, Len
@ 2003-07-18  5:04 ` Hugh Dickins
  0 siblings, 0 replies; 2+ messages in thread
From: Hugh Dickins @ 2003-07-18  5:04 UTC (permalink / raw)
  To: Brown, Len
  Cc: Grover, Andrew, 'ACPI-Devel mailing list',
	'linux-kernel@vger.kernel.org', 'Marcelo Tosatti'

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-07-18  4:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-18  2:14 "noht" (RE: ACPI patches updated (20030714)) Brown, Len
2003-07-18  5:04 ` Hugh Dickins

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).