lkml.org 
[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
    Date
    From


    >On Fri, 30 Nov 2007 14:06:55 -0800
    >"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> wrote:
    >
    >Please dont go off-list like this. I put Mark's original
    >mailing list cc's
    >back.

    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.

    Thanks,
    Venki
    -
    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/

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