[lkml]   [2011]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Patch] idle governor: Avoid lock acquisition to read pm_qos before entering idle
    On Wed, 2011-02-09 at 21:10 -0800, mark gross wrote:

    > I'm surprised by this as the last update to the pm_qos replaced the
    > lists with a O(1) data structure so there was no more walking of pending
    > requests.

    But you need to acquire a lock before you can read the value on the list
    within the function pm_qos_request. This is a problem if there are a
    lot of cpus doing so.

    > What is the profile after the patch the Plist should be only one
    > dereference and an if instruction slower than a cached value.

    After the patch, the acquisition of the lock on plist go away from the
    profile, and I see a 12% improvement in throughput to the message
    passing benchmark I was running.

    > Does your patch remove the need for the locks because if it doesn't I
    > don't see how it will make much of a difference?

    We still need the lock to update/remove/insert values in the plist and
    to update the cached value. The intention of the patch is to avoid lock
    acquisition by reading from a cached value that is up to date. Lock
    acquisition is needed --every time-- when a cpu go into idle, which is
    bad as you want to let a cpu go to idle ASAP.


     \ /
      Last update: 2011-02-10 18:29    [W:0.023 / U:62.260 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site