19 Aug, 2011

1 commit


16 Aug, 2011

4 commits

  • This allows for example:
    cpupower -c 2-4,6 monitor -m Mperf
    |Mperf
    PKG |CORE|CPU | C0 | Cx | Freq
    0| 8| 4| 2.42| 97.58| 1353
    0| 16| 2| 14.38| 85.62| 1928
    0| 24| 6| 1.76| 98.24| 1442
    1| 16| 3| 15.53| 84.47| 1650

    CPUs always get resorted for package, core then cpu id if it could get read out
    (or however you name these topology levels...).
    Still this is a nice way to keep the overview if a test binary is bound to
    a specific CPU or if one wants to show all CPUs inside a package or similar.

    Still missing: Do not measure not available cores to reduce the overhead
    and achieve better results.

    Signed-off-by: Thomas Renninger
    Signed-off-by: Dominik Brodowski

    Thomas Renninger
     
  • Before, checking for offlined CPUs was done dirty and
    it was checked whether topology parsing returned -1 values.
    But this is a valid case on a Xen (and possibly other) kernels.

    Do proper online/offline checking, also take CONFIG_HOTPLUG_CPU
    option into account (no /sys/devices/../cpuX/online file).

    Signed-off-by: Thomas Renninger
    Signed-off-by: Dominik Brodowski

    Thomas Renninger
     
  • By taking error values of:
    sysfs_get_idlestate_count(..);
    into account.

    Signed-off-by: Thomas Renninger
    Signed-off-by: Dominik Brodowski

    Thomas Renninger
     
  • Which makes the implementation independent from cpufreq drivers.
    Therefore this would also work on a Xen kernel where the hypervisor
    is doing frequency switching and idle entering.

    Signed-off-by: Thomas Renninger
    Signed-off-by: Dominik Brodowski

    Thomas Renninger
     

30 Jul, 2011

2 commits

  • Signed-off-by: Dominik Brodowski

    Dominik Brodowski
     
  • CPU power consumption vs performance tuning is no longer
    limited to CPU frequency switching anymore: deep sleep states,
    traditional dynamic frequency scaling and hidden turbo/boost
    frequencies are tied close together and depend on each other.
    The first two exist on different architectures like PPC, Itanium and
    ARM, the latter (so far) only on X86. On X86 the APU (CPU+GPU) will
    only run most efficiently if CPU and GPU has proper power management
    in place.

    Users and Developers want to have *one* tool to get an overview what
    their system supports and to monitor and debug CPU power management
    in detail. The tool should compile and work on as many architectures
    as possible.

    Once this tool stabilizes a bit, it is intended to replace the
    Intel-specific tools in tools/power/x86

    Signed-off-by: Dominik Brodowski

    Dominik Brodowski