Re: [PATCH 14/14] ACPI: Provide/sys/devices/system/cpu/cpuN/deconfigure

[Alex Chiang]

* Andi Kleen <ak@xxxxxxxxxxxxxxx>:
> Alex Chiang wrote:
>> Provide a new sysfs interface for CPU deconfiguration.
>>
>> Since no vendors can agree on terminology for related but slightly
>> different features, provide a method for a platform to implement
>> its own version of what it thinks 'deconfiguring' a CPU might be.
>>
>> Provide an HP-specific CPU deconfiguration implementation.
>
> Why are you ccing this to linux-arch? Dropped.

Hm, sorry.

I thought it would have been weird to send patches 1-13 / 14 to
linux-arch, but not send 14 / 14. Perhaps I should set a Reply-to:
in the future?

> What is the standard status of these new SCFG and ECFG tables?
> Have they been submitted for possible inclusion in ACPI? And is
> there a spec available? I can't say I'm really thrilled with
> having HP specific support in there.
>
> It would be better at least if you could reserve the table
> names and  then drop the HP DMI check. This is needed anyways,
> otherwise the  standard at some point could add different
> ECFG/SCFG tables.

These are not new tables -- they are methods that live underneath
processor objects in the namespace.

Yes, they are specific to HP, but because they are methods, there
shouldn't be any collision with other vendors defining methods
with the same name (with the DMI check).

>> + * After echo'ing 0 or 1 into deconfigure, cat'ing the file will
>> + * return the next boot's status. However, the CPU will not actually
>> + * be deconfigured until the next boot.
>
> Now that seems like weird semantics for a public fixed API.
> What happens when some other vendor adds hot deconfiguration?

Yeah, I'm not totally happy with it either. But I'd like to
clarify -- are you concerned with the name of the interface
(deconfigure) or the "nothing happens until next boot" behavior?

Would it help if I renamed it to "enabled" and had something
like:

	echo 0 > enabled
	echo 1 > enabled
	cat enabled

And then that would map to vendor-specific behavior?

Or is it really the "nothing happens until next boot" thing that
bothers you?

> My feeling is that this seems to be overly specific to your
> BIOS and might better belong into some separate management
> tool. At least until we can define a nice general API for this
> with clear semantics.  

Well, life would be a lot easier if we had a generic way to poke
at ACPI methods, but dev_acpi has been rejected multiple times.
;)

On a more serious note, my fear is that an interface like this is
not going to have agreement / clear semantics for a long time
because one vendor is going to want to call it 'deconfigured' and
another one might want to call it 'disabled' and a third might
want to call it 'puppy_dogs' and they'll all be kinda related but
not exactly the same.

That's why I was going down the road of creating at least one
generic interface, but with vendor-specific semantics.

Calling it 'enabled' might be a better idea.

> For what systems is this anyways?

We have HP ia64 systems shipping today that support this.

Thanks.

/ac

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/