[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 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 <>

    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.


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