1. 16 4月, 2015 1 次提交
  2. 20 12月, 2014 2 次提交
  3. 15 12月, 2014 1 次提交
  4. 05 12月, 2014 1 次提交
    • P
      tools: cpupower: fix return checks for sysfs_get_idlestate_count() · 16b7c275
      Prarit Bhargava 提交于
      Red Hat and Fedora use a bug reporting tool that gathers data about
      "broken" systems called sosreport.  Among other things, it includes the
      output of 'cpupower idle-info'.  Executing 'cpupower idle-info' on a
      system that has cpuidle disabled via 'cpuidle.off=1' results in a 300
      second hang in the cpupower application.
      
      ie)
      [root@intel-brickland-05]# cpupower idle-info
      Could not determine cpuidle driver
      
      Analyzing CPU 0:
      Number of idle states: -19
      [hang]
      
      The problem is that the cpupower code only checks for a zero return from
      sysfs_get_idlestate_count().  The function can return -ENODEV (-19) as
      above.  This patch fixes callers to sysfs_get_idlestate_count() to check
      the right return values.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      16b7c275
  5. 30 7月, 2014 2 次提交
  6. 20 7月, 2014 1 次提交
  7. 17 5月, 2014 4 次提交
  8. 07 5月, 2014 1 次提交
    • P
      PM / tools: cpupower: add option to display values without round offs · e091abc7
      Prarit Bhargava 提交于
      The command "cpupower frequency-info" can be used when using cpupower to
      monitor and test processor behaviour to determine if the processor is
      behaving as expected.  This data can be compared to the output of
      /proc/cpuinfo or the output of
      /sys/devices/system/cpu/cpuX/cpufreq/scaling_available_frequencies
      to determine if the cpu is in an expected state.
      
      When doing this I noticed comparison test failures due to the way the
      data is displayed in cpupower.  For example,
      
      [root@intel-s3e37-02 cpupower]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
      2262000 2261000 2128000 1995000 1862000 1729000 1596000 1463000 1330000
      1197000 1064000
      
      compared to
      
      [root@intel-s3e37-02 cpupower]# cpupower frequency-info
      analyzing CPU 0:
        driver: acpi-cpufreq
        CPUs which run at the same hardware frequency: 0
        CPUs which need to have their frequency coordinated by software: 0
        maximum transition latency: 10.0 us.
        hardware limits: 1.06 GHz - 2.26 GHz
        available frequency steps: 2.26 GHz, 2.26 GHz, 2.13 GHz, 2.00 GHz, 1.86 GHz, 1.73 GHz, 1.60 GHz, 1.46 GHz, 1.33 GHz, 1.20 GHz, 1.06 GHz
        available cpufreq governors: conservative, userspace, powersave, ondemand, performance
        current policy: frequency should be within 1.06 GHz and 2.26 GHz.
                        The governor "performance" may decide which speed to use
                        within this range.
        current CPU frequency is 2.26 GHz (asserted by call to hardware).
        boost state support:
          Supported: yes
          Active: yes
      
      shows very different values for the available frequency steps.  The cpupower
      output rounds off values at 2 decimal points and this causes problems with
      test scripts.  For example, with the data above,
      
      1.064 is 1.06
      1.197 is 1.20
      1.596 is 1.60
      1.995 is 2.00
      2.128 is 2.13
      
      and most confusingly,
      
      2.261 is 2.26
      2.262 is 2.26
      
      Truncating these values serves no real purpose other than making the output
      pretty.  Since the default has been to round off these values I am adding
      a -n/--no-rounding option to the cpupower utility that will display the
      data without rounding off the still significant digits.
      
      After patch,
      
      analyzing CPU 0:
        driver: acpi-cpufreq
        CPUs which run at the same hardware frequency: 0
        CPUs which need to have their frequency coordinated by software: 0
        maximum transition latency: 10.000 us.
        hardware limits: 1.064000 GHz - 2.262000 GHz
        available frequency steps: 2.262000 GHz, 2.261000 GHz, 2.128000 GHz, 1.995000 GHz, 1.862000 GHz, 1.729000 GHz, 1.596000 GHz, 1.463000 GHz, 1.330000 GHz, 1.197000 GHz, 1.064000 GHz
        available cpufreq governors: conservative, userspace, powersave, ondemand, performance
        current policy: frequency should be within 1.064000 GHz and 2.262000 GHz.
                        The governor "performance" may decide which speed to use
                        within this range.
        current CPU frequency is 2.262000 GHz (asserted by call to hardware).
        boost state support:
          Supported: yes
          Active: yes
      Acked-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      [rjw: Subject]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e091abc7
  9. 08 1月, 2014 1 次提交
  10. 18 12月, 2013 1 次提交
  11. 26 11月, 2013 1 次提交
  12. 05 7月, 2013 5 次提交
  13. 28 11月, 2012 6 次提交
  14. 17 5月, 2012 1 次提交
    • P
      sched: Remove stale power aware scheduling remnants and dysfunctional knobs · 8e7fbcbc
      Peter Zijlstra 提交于
      It's been broken forever (i.e. it's not scheduling in a power
      aware fashion), as reported by Suresh and others sending
      patches, and nobody cares enough to fix it properly ...
      so remove it to make space free for something better.
      
      There's various problems with the code as it stands today, first
      and foremost the user interface which is bound to topology
      levels and has multiple values per level. This results in a
      state explosion which the administrator or distro needs to
      master and almost nobody does.
      
      Furthermore large configuration state spaces aren't good, it
      means the thing doesn't just work right because it's either
      under so many impossibe to meet constraints, or even if
      there's an achievable state workloads have to be aware of
      it precisely and can never meet it for dynamic workloads.
      
      So pushing this kind of decision to user-space was a bad idea
      even with a single knob - it's exponentially worse with knobs
      on every node of the topology.
      
      There is a proposal to replace the user interface with a single
      3 state knob:
      
       sched_balance_policy := { performance, power, auto }
      
      where 'auto' would be the preferred default which looks at things
      like Battery/AC mode and possible cpufreq state or whatever the hw
      exposes to show us power use expectations - but there's been no
      progress on it in the past many months.
      
      Aside from that, the actual implementation of the various knobs
      is known to be broken. There have been sporadic attempts at
      fixing things but these always stop short of reaching a mergable
      state.
      
      Therefore this wholesale removal with the hopes of spurring
      people who care to come forward once again and work on a
      coherent replacement.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1326104915.2442.53.camel@twinsSigned-off-by: NIngo Molnar <mingo@kernel.org>
      8e7fbcbc
  15. 03 3月, 2012 5 次提交
  16. 19 8月, 2011 2 次提交
  17. 16 8月, 2011 4 次提交
  18. 30 7月, 2011 1 次提交
新手
引导
客服 返回
顶部