[lkml]   [2007]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree

    >On Fri, 30 Nov 2007 14:06:55 -0800
    >"Pallipadi, Venkatesh" <> 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
    >> migrated.
    >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
    >below patch
    >> will not really work with cpuidle.
    >> Selecting max_cstate at boot time as a debug option still
    >works without
    >> 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
    >however is:
    >> 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
    >thing. Perhaps
    >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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-11-30 23:45    [W:0.023 / U:13.212 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site