[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.122 / U:5.232 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site