Messages in this thread | | | Subject | Re: [Patch] idle governor: Avoid lock acquisition to read pm_qos before entering idle | From | Tim Chen <> | Date | Thu, 10 Feb 2011 09:27:24 -0800 |
| |
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.
Tim
| |