[lkml]   [2011]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: cpuidle asymmetry (was Re: [RFC PATCH V4 5/5] cpuidle: cpuidle driver for apm)

    On 03/31/2011 07:47 AM, Len Brown wrote:
    >>>> Maybe there is some other way to handle asymmetry ??
    > I mis-spoke on asymmetry.
    > Moorestown is already an example of an asymmetric system,
    > since its deepest c-state is available on cpu0, but not on cpu1.
    > So it needs different tables for each cpu.
    > I think what would work is a default c-state table for the system,
    > and the ability of a per-cpu override table. I think that would
    > gracefully handle the case of many identical cpus, and also systems
    > with different tables per cpu.

    Hi Len,

    What would happen if a cpu enters a state which wasn't
    reported for it? I am wondering if an approach like union
    of states of each would work.

    Can we handle asymmetry through checking and demotion inside the
    routine itself; just like you are proposing as dev->prepare
    alternative? But I guess this may not be efficient if this
    happens often.

    I am not sure if having a per-cpu override would be very tidy
    (ideas ?); and much better than per-cpu stuff. So just want to check
    what would be the best way forward?

    > The same goes for write-access to the tables.
    > In the typical case, a single table can be shared for the entire system
    > and nobody will be writing to it. However, with the governor changes
    > to call dev->prepare and sift through all the states to find the
    > legal one with the lowest power_usage... There is software today
    > out of tree that updates that power_usage entry from prepare().
    > As I mentioned, I'm not fond of that mechanism - it looks racey
    > to me. I'd rather see the capability of a drivers idle handler
    > to demote to another handler in the driver and for the accounting
    > to not get messed up when that happens. I think the way to do that
    > is to let the driver do the accounting rather than doing it in
    > the cpuidle caller.

    I agree with this; we should move update of statistics inside the
    driver routines (enter routines). They already take device/stats
    structure as parameter.


     \ /
      Last update: 2011-04-01 09:05    [W:0.023 / U:4.244 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site