>On Fri, 30 Nov 2007 14:06:55 -0800
>"Pallipadi, Venkatesh" <[email protected]> wrote:
>Please dont go off-list like this. I put Mark's original
>mailing list cc's
Sorry for missing some cc's earlier. I blindly did a reply-all to the
mm-commits mail I got.
>> I will have to Nack this. The reason max_cstate was initentionally
>> removed due to couple of reasons:
>It broke userspace without any warning or migration period, afaict.
Yes. That's true. I will have to take the blame for that. It has been
known for a while during cpuidle development. But, it was never
documented as deprecating.
>> 1) All in kernel users of max_cstate should rather be using
>> pm_qos/latency interfaces. All such max_cstate usages must already be
>That code isn't merged.
All kernel part is already merged. I mean, there are do drivers that
depend on max_cstate. They use latency_notifier thing today and their
migration to pm_qos part is not merged yet.
>> 2) Supporting max_cstate as a dynamic parameter cleanly is no longer
>> possible in acpi/processor_idle.c as the C-state policy has moved to
>> cpuidle instead. It can be done if it is needed. But, just
>> will not really work with cpuidle.
>> Selecting max_cstate at boot time as a debug option still
>> this patch.
>> So, just this patch will not get back the functionality with cpuidle.
>> Infact changing it at run time will have no effect. Question
>> Is there a real need to revive this parameter so that user can change
>> max_cstate at run time?
>It is not known whether Mark is actually writing to this
>read-only permissions would be a suitable fix?
Exporting it as read only should be OK. We also need to know if there
are hard user space dependency on writing to this from userspace.
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/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]