1. 29 May, 2011 3 commits
    • Len Brown's avatar
      x86 idle: clarify AMD erratum 400 workaround · 02c68a02
      Len Brown authored
      The workaround for AMD erratum 400 uses the term "c1e" falsely suggesting:
      1. Intel C1E is somehow involved
      2. All AMD processors with C1E are involved
      
      Use the string "amd_c1e" instead of simply "c1e" to clarify that
      this workaround is specific to AMD's version of C1E.
      Use the string "e400" to clarify that the workaround is specific
      to AMD processors with Erratum 400.
      
      This patch is text-substitution only, with no functional change.
      
      cc: x86@kernel.org
      Acked-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      02c68a02
    • Tim Chen's avatar
      idle governor: Avoid lock acquisition to read pm_qos before entering idle · 333c5ae9
      Tim Chen authored
      Thanks to the reviews and comments by Rafael, James, Mark and Andi.
      Here's version 2 of the patch incorporating your comments and also some
      update to my previous patch comments.
      
      I noticed that before entering idle state, the menu idle governor will
      look up the current pm_qos target value according to the list of qos
      requests received.  This look up currently needs the acquisition of a
      lock to access the list of qos requests to find the qos target value,
      slowing down the entrance into idle state due to contention by multiple
      cpus to access 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 cpu cores are active in test system, I see the following profile with
      37.82% of cpu cycles spent in contention of pm_qos_lock:
      
      -     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
      
      A better approach will be to cache the updated pm_qos target value so
      reading it does not require lock acquisition as in the patch below.
      With this patch the contention for pm_qos_lock is removed and I saw a
      2.2X increase in throughput for my message passing workload.
      
      cc: stable@kernel.org
      Signed-off-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
      Acked-by: default avatarAndi Kleen <ak@linux.intel.com>
      Acked-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      Acked-by: default avatarmark gross <markgross@thegnar.org>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      333c5ae9
    • Tero Kristo's avatar
      cpuidle: menu: fixed wrapping timers at 4.294 seconds · 7467571f
      Tero Kristo authored
      Cpuidle menu governor is using u32 as a temporary datatype for storing
      nanosecond values which wrap around at 4.294 seconds. This causes errors
      in predicted sleep times resulting in higher than should be C state
      selection and increased power consumption. This also breaks cpuidle
      state residency statistics.
      
      cc: stable@kernel.org # .32.x through .39.x
      Signed-off-by: default avatarTero Kristo <tero.kristo@nokia.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      7467571f
  2. 15 Mar, 2011 1 commit
  3. 14 Mar, 2011 36 commits