lkml.org 
[lkml]   [2011]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [Patch] idle governor: Avoid lock acquisition to read pm_qos before entering idle
    Date
    On Thursday, February 10, 2011, James Bottomley wrote:
    > On Wed, 2011-02-09 at 17:21 -0800, Tim Chen wrote:
    > > I noticed that before entering idle state, the menu idle governor will
    > > look up the current pm_qos value according to the list of qos request
    > > received. This look up currently needs the acquisition of a lock to go
    > > down a list of qos requests to find the qos value, slowing down the
    > > entrance into idle state due to contention by multiple cpus to traverse
    > > this list. The contention is severe when there are a lot of cpus waking
    > > and going into idle. For example, for a simple workload that has 32
    > > pair of processes ping ponging messages to each other, where 64 cores
    > > cores are active in test system, I see the following profile:
    > >
    > > - 37.82% swapper [kernel.kallsyms] [k]
    > > _raw_spin_lock_irqsave
    > > - _raw_spin_lock_irqsave
    > > - 95.65% pm_qos_request
    > > menu_select
    > > cpuidle_idle_call
    > > - cpu_idle
    > > 99.98% start_secondary
    > >
    > > Perhaps a better approach will be to cache the updated pm_qos value so
    > > reading it does not require lock acquisition as in the patch below.
    > >
    > > Tim
    > >
    > > Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    >
    > What you say is true as long as the value is 32 bits ... perhaps a note
    > of that should be made somewhere?
    >
    > Otherwise, it looks like a good lockless optimisation on the read path,
    > so you can add my ack.

    Thanks James, I'm going to take the patch.

    Rafael


    \
     
     \ /
      Last update: 2011-02-10 19:53    [W:0.020 / U:30.648 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site