I think there should be a boot-option to use ACPI for boot-time
configuration tables, but to not load the driver for run-time event
handling. This is useful for enabling HT on systems with broken ACPI
run-time BIOS.
UnitedLinux uses "acpi=oldboot" for this. While 'old' will become ambiguous
when today's "new" becomes tomorrow's "old";-), I do like "acpi={something}"
rather than complicating matters with non "acpi=" syntax.
Re: "acpismp=force"
I wouldn't miss it. Sounds unanimous.
Re: "noht"
To disable HT on a uni-processor, wouldn't it be preferable to simply run
the UP kernel rather than the SMP kernel with HT disabled? That leaves SMP
systems, where either the BIOS could disable it (it is a BIOS bug if it
can't), or as a last resort CONFIG_X86_HT (2.5) could be config'd out of the
kernel. I guess I've talked myself into not missing "noht" also.
Cheers,
-Len
> -----Original Message-----
> From: Arjan van de Ven [mailto:[email protected]]
> Sent: Monday, June 23, 2003 7:54 AM
> To: Hugh Dickins
> Cc: Grover, Andrew; Arjan van de Ven; Andrew Morton;
> [email protected]; [email protected];
> [email protected]
> Subject: Re: [BK PATCH] acpismp=force fix
>
>
> On Mon, Jun 23, 2003 at 12:46:38PM +0100, Hugh Dickins wrote:
> > Certainly reliance on "acpismp=force" should be removed if
> it's crept
> > back in. But what should we do about "noht"? Wave a fond goodbye,
> > and remove it's associated code and Documentation from 2.4 and 2.5
> > trees, rely on changing the BIOS setting instead? Or bring it back
> > into action?
>
> for 2.4 it's no problem to honor it really code wise; and it's
> useful for machines where you can't disable HT in the bios but where
> your particular workload doesn't positively benefit from HT.
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Thu, 26 Jun 2003, Brown, Len wrote:
>
> I think there should be a boot-option to use ACPI for boot-time
> configuration tables, but to not load the driver for run-time event
> handling. This is useful for enabling HT on systems with broken ACPI
> run-time BIOS.
I may be wrong, I think it was Arjan persuaded AndrewG to allow the
acpitable.c code into 2.5 for this case. At present it's enabled by
config option instead of boot option, in both 2.5 (where the config
option didn't actually work, patch posted for that a couple of days ago)
and in 2.4.22-pre (which thus diverges from 2.4.21). That surprises me,
but I'd definitely defer to Arjan's preference.
> UnitedLinux uses "acpi=oldboot" for this. While 'old' will become ambiguous
> when today's "new" becomes tomorrow's "old";-), I do like "acpi={something}"
> rather than complicating matters with non "acpi=" syntax.
I agree with you.
> Re: "acpismp=force"
> I wouldn't miss it. Sounds unanimous.
It did have some point before, recent changes have rendered it pointless,
and even if those changes get revised, there'll be a better way than the
confusing "acpismp=force".
> Re: "noht"
> To disable HT on a uni-processor, wouldn't it be preferable to simply run
> the UP kernel rather than the SMP kernel with HT disabled?
Yes, though wouldn't BIOS be able to disable it on those too?
> That leaves SMP
> systems, where either the BIOS could disable it (it is a BIOS bug if it
> can't), or as a last resort CONFIG_X86_HT (2.5) could be config'd out of the
> kernel. I guess I've talked myself into not missing "noht" also.
I fathered "noht", so feel some responsibility for it. In its present
state it's simply buggered in both 2.5 and 2.4.22-pre, and I'd much rather
kill it off than leave it around in that misery. If we can always switch
off in BIOS instead, I guess it's redundant and should go. Arjan remarked
that it's no problem to honor it codewise in 2.4: up to 2.4.21 it was easy,
but now beyond what I can safely mess with - I'm hoping someone (perhaps
beginning with A?) might reprieve it, but if not I'll send patches to
remove it from 2.4 and 2.5 in a few weeks time.
Hugh
On Fri, Jun 27, 2003 at 12:58:17PM +0100, Hugh Dickins wrote:
> and in 2.4.22-pre (which thus diverges from 2.4.21). That surprises me,
> but I'd definitely defer to Arjan's preference.
for 2.4 it's a matter of compatability; also Andrew said it made the
code cleaner actually.
> > Re: "acpismp=force"
> > I wouldn't miss it. Sounds unanimous.
>
> It did have some point before, recent changes have rendered it pointless,
> and even if those changes get revised, there'll be a better way than the
> confusing "acpismp=force".
it became mostly useless when the automatic detection based on CPU flag went it
> > Re: "noht"
> > To disable HT on a uni-processor, wouldn't it be preferable to simply run
> > the UP kernel rather than the SMP kernel with HT disabled?
>
> Yes, though wouldn't BIOS be able to disable it on those too?
not all bioses have such a setting unfortionatly so it remains a
useful option.
>>>>> "brown," == Brown, Len <[email protected]> writes:
Hi
brown,> To disable HT on a uni-processor, wouldn't it be preferable to simply run
brown,> the UP kernel rather than the SMP kernel with HT disabled? That leaves SMP
brown,> systems, where either the BIOS could disable it (it is a BIOS bug if it
brown,> can't), or as a last resort CONFIG_X86_HT (2.5) could be config'd out of the
brown,> kernel. I guess I've talked myself into not missing "noht" also.
noht is very useful for distributions, we already have to do a lot of
kernels, any option that "mandates" to compile a different kernel is
just bad (IMHO).
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy