RE: [BK PATCH] acpismp=force fix

RE: [BK PATCH] acpismp=force fix

[Grover, Andrew]

> From: Andrew Morton [mailto:akpm@digeo.com] 
> >    ACPI: make it so acpismp=force works (reported by Andrew Morton)

> But prior to 2.5.72, CPU enumeration worked fine without 
> acpismp=force. 
> Now it is required.  How come?

(I'm taking the liberty to update the subject, which I accidentally left
blank)

Because 2.4 has that behavior. One objection that people raised to
applying the 2.4 ACPI patch was that it changed that behavior. So I made
an effort to keep it there.

I think out of sheer inertia I also re-added it to the 2.5 tree.
Probably shouldn't have.

Does anyone have a reason why acpismp=force should be in 2.5/6? If not
I'll go ahead and zap it (again), and everyone should just be aware that
this is another way that 2.4 and 2.5 differ.

Regards -- Andy

Re: [BK PATCH] acpismp=force fix

[Andrew Morton]

"Grover, Andrew" <andrew.grover@intel.com> wrote:
>
> Does anyone have a reason why acpismp=force should be in 2.5/6?

I can't think of one.

> If not I'll go ahead and zap it (again)

zap away.  Dave Jones is maintaining a "stuff which changed" document. 
Please send him a paragraph.

RE: [BK PATCH] acpismp=force fix

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On Mon, 2003-06-23 at 09:43, Grover, Andrew wrote:
> > From: Andrew Morton [mailto:akpm@digeo.com] 
> > >    ACPI: make it so acpismp=force works (reported by Andrew Morton)
> 
> > But prior to 2.5.72, CPU enumeration worked fine without 
> > acpismp=force. 
> > Now it is required.  How come?
> 
> (I'm taking the liberty to update the subject, which I accidentally left
> blank)
> 
> Because 2.4 has that behavior. One objection that people raised to
> applying the 2.4 ACPI patch was that it changed that behavior. So I made
> an effort to keep it there.

in 2.4 it is absolutely not mantadory; it's default actually if the cpu
advertises the "ht" flag.....

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: [BK PATCH] acpismp=force fix

[Hugh Dickins]

On Mon, 23 Jun 2003, Arjan van de Ven wrote:
> On Mon, 2003-06-23 at 09:43, Grover, Andrew wrote:
> > > From: Andrew Morton [mailto:akpm@digeo.com] 
> > > >    ACPI: make it so acpismp=force works (reported by Andrew Morton)
> > 
> > > But prior to 2.5.72, CPU enumeration worked fine without 
> > > acpismp=force. 
> > > Now it is required.  How come?
> > 
> > (I'm taking the liberty to update the subject, which I accidentally left
> > blank)
> > 
> > Because 2.4 has that behavior. One objection that people raised to
> > applying the 2.4 ACPI patch was that it changed that behavior. So I made
> > an effort to keep it there.
> 
> in 2.4 it is absolutely not mantadory; it's default actually if the cpu
> advertises the "ht" flag.....

Right, enabling HT hasn't relied on "acpismp=force" since 2.4.18.
Requiring "acpismp=force" now in 2.4 or 2.5 is just a step backwards.

But when we changed to HT by default, I added bootparam "noht" to
disable it if it was found troublesome.  Last time I checked, "noht"
was ineffectual on 2.5, and perhaps now it's ineffectual on 2.4.22-pre?

(If I remember right, in 2.5 it did have one effect, determining whether
the "ht" flag is shown in /proc/cpuinfo: but it was intended to be more
useful than that.)

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?

Hugh

Re: [BK PATCH] acpismp=force fix

[Arjan van de Ven]

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.

RE: [BK PATCH] acpismp=force fix

[Brown, Len]

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:arjanv@redhat.com] 
> Sent: Monday, June 23, 2003 7:54 AM
> To: Hugh Dickins
> Cc: Grover, Andrew; Arjan van de Ven; Andrew Morton; 
> torvalds@transmeta.com; acpi-devel@lists.sourceforge.net; 
> linux-kernel@vger.kernel.org
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

RE: [BK PATCH] acpismp=force fix

[Hugh Dickins]

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

Re: [BK PATCH] acpismp=force fix

[Arjan van de Ven]

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.

Re: [BK PATCH] acpismp=force fix

[Juan Quintela]

>>>>> "brown," == Brown, Len <len.brown@intel.com> 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