1. 02 10月, 2013 2 次提交
  2. 31 8月, 2013 1 次提交
  3. 30 8月, 2013 3 次提交
  4. 29 8月, 2013 1 次提交
    • L
      cpuidle: big.LITTLE: vexpress-TC2 CPU idle driver · 14d2c34c
      Lorenzo Pieralisi 提交于
      The big.LITTLE architecture is composed of two clusters of cpus. One cluster
      contains less powerful but more energy efficient processors and the other
      cluster groups the powerful but energy-intensive cpus.
      
      The TC2 testchip implements two clusters of CPUs (A7 and A15 clusters in
      a big.LITTLE configuration) connected through a CCI interconnect that manages
      coherency of their respective L2 caches and intercluster distributed
      virtual memory messages (DVM).
      
      TC2 testchip integrates a power controller that manages cores resets, wake-up
      IRQs and cluster low-power states. Power states are managed at cluster
      level, which means that voltage is removed from a cluster iff all cores
      in a cluster are in a wfi state. Single cores can enter a reset state
      which is identical to wfi in terms of power consumption but simplifies the
      way cluster states are entered.
      
      This patch provides a multiple driver CPU idle implementation for TC2
      which paves the way for a generic big.LITTLE idle driver for all
      upcoming big.LITTLE based systems on chip.
      
      The driver relies on the MCPM infrastructure to coordinate and manage
      core power states; in particular MCPM allows to suspend specific cores
      and hides the CPUs coordination required to shut-down clusters of CPUs.
      
      Power down sequences for the respective clusters are implemented in the
      MCPM TC2 backend, with all code needed to clean caches and exit coherency.
      
      The multiple driver CPU idle infrastructure allows to define different
      C-states for big and little cores, determined at boot by checking the
      part id of the possible CPUs and initializing the respective logical
      masks in the big and little drivers.
      
      Current big.little systems are composed of A7 and A15 clusters, as
      implemented in TC2, but in the future that may change and the driver
      will have evolve to retrieve what is a 'big' cpu and what is a 'little'
      cpu in order to build the correct topology.
      
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Amit Kucheria <amit.kucheria@linaro.org>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      14d2c34c
  5. 23 8月, 2013 8 次提交
  6. 15 8月, 2013 1 次提交
  7. 12 8月, 2013 2 次提交
  8. 29 7月, 2013 2 次提交
    • R
      Revert "cpuidle: Quickly notice prediction failure for repeat mode" · 14851912
      Rafael J. Wysocki 提交于
      Revert commit 69a37bea (cpuidle: Quickly notice prediction failure for
      repeat mode), because it has been identified as the source of a
      significant performance regression in v3.8 and later as explained by
      Jeremy Eder:
      
        We believe we've identified a particular commit to the cpuidle code
        that seems to be impacting performance of variety of workloads.
        The simplest way to reproduce is using netperf TCP_RR test, so
        we're using that, on a pair of Sandy Bridge based servers.  We also
        have data from a large database setup where performance is also
        measurably/positively impacted, though that test data isn't easily
        share-able.
      
        Included below are test results from 3 test kernels:
      
        kernel       reverts
        -----------------------------------------------------------
        1) vanilla   upstream (no reverts)
      
        2) perfteam2 reverts e11538d1
      
        3) test      reverts 69a37bea
                             e11538d1
      
        In summary, netperf TCP_RR numbers improve by approximately 4%
        after reverting 69a37bea.  When
        69a37bea is included, C0 residency
        never seems to get above 40%.  Taking that patch out gets C0 near
        100% quite often, and performance increases.
      
        The below data are histograms representing the %c0 residency @
        1-second sample rates (using turbostat), while under netperf test.
      
        - If you look at the first 4 histograms, you can see %c0 residency
          almost entirely in the 30,40% bin.
        - The last pair, which reverts 69a37bea,
          shows %c0 in the 80,90,100% bins.
      
        Below each kernel name are netperf TCP_RR trans/s numbers for the
        particular kernel that can be disclosed publicly, comparing the 3
        test kernels.  We ran a 4th test with the vanilla kernel where
        we've also set /dev/cpu_dma_latency=0 to show overall impact
        boosting single-threaded TCP_RR performance over 11% above
        baseline.
      
        3.10-rc2 vanilla RX + c0 lock (/dev/cpu_dma_latency=0):
        TCP_RR trans/s 54323.78
      
        -----------------------------------------------------------
        3.10-rc2 vanilla RX (no reverts)
        TCP_RR trans/s 48192.47
      
        Receiver %c0
            0.0000 -    10.0000 [     1]: *
           10.0000 -    20.0000 [     0]:
           20.0000 -    30.0000 [     0]:
           30.0000 -    40.0000 [    59]:
        ***********************************************************
           40.0000 -    50.0000 [     1]: *
           50.0000 -    60.0000 [     0]:
           60.0000 -    70.0000 [     0]:
           70.0000 -    80.0000 [     0]:
           80.0000 -    90.0000 [     0]:
           90.0000 -   100.0000 [     0]:
      
        Sender %c0
            0.0000 -    10.0000 [     1]: *
           10.0000 -    20.0000 [     0]:
           20.0000 -    30.0000 [     0]:
           30.0000 -    40.0000 [    11]: ***********
           40.0000 -    50.0000 [    49]:
        *************************************************
           50.0000 -    60.0000 [     0]:
           60.0000 -    70.0000 [     0]:
           70.0000 -    80.0000 [     0]:
           80.0000 -    90.0000 [     0]:
           90.0000 -   100.0000 [     0]:
      
        -----------------------------------------------------------
        3.10-rc2 perfteam2 RX (reverts commit
        e11538d1)
        TCP_RR trans/s 49698.69
      
        Receiver %c0
            0.0000 -    10.0000 [     1]: *
           10.0000 -    20.0000 [     1]: *
           20.0000 -    30.0000 [     0]:
           30.0000 -    40.0000 [    59]:
        ***********************************************************
           40.0000 -    50.0000 [     0]:
           50.0000 -    60.0000 [     0]:
           60.0000 -    70.0000 [     0]:
           70.0000 -    80.0000 [     0]:
           80.0000 -    90.0000 [     0]:
           90.0000 -   100.0000 [     0]:
      
        Sender %c0
            0.0000 -    10.0000 [     1]: *
           10.0000 -    20.0000 [     0]:
           20.0000 -    30.0000 [     0]:
           30.0000 -    40.0000 [     2]: **
           40.0000 -    50.0000 [    58]:
        **********************************************************
           50.0000 -    60.0000 [     0]:
           60.0000 -    70.0000 [     0]:
           70.0000 -    80.0000 [     0]:
           80.0000 -    90.0000 [     0]:
           90.0000 -   100.0000 [     0]:
      
        -----------------------------------------------------------
        3.10-rc2 test RX (reverts 69a37bea
        and e11538d1)
        TCP_RR trans/s 47766.95
      
        Receiver %c0
            0.0000 -    10.0000 [     1]: *
           10.0000 -    20.0000 [     1]: *
           20.0000 -    30.0000 [     0]:
           30.0000 -    40.0000 [    27]: ***************************
           40.0000 -    50.0000 [     2]: **
           50.0000 -    60.0000 [     0]:
           60.0000 -    70.0000 [     2]: **
           70.0000 -    80.0000 [     0]:
           80.0000 -    90.0000 [     0]:
           90.0000 -   100.0000 [    28]: ****************************
      
        Sender:
            0.0000 -    10.0000 [     1]: *
           10.0000 -    20.0000 [     0]:
           20.0000 -    30.0000 [     0]:
           30.0000 -    40.0000 [    11]: ***********
           40.0000 -    50.0000 [     0]:
           50.0000 -    60.0000 [     1]: *
           60.0000 -    70.0000 [     0]:
           70.0000 -    80.0000 [     3]: ***
           80.0000 -    90.0000 [     7]: *******
           90.0000 -   100.0000 [    38]: **************************************
      
        These results demonstrate gaining back the tendency of the CPU to
        stay in more responsive, performant C-states (and thus yield
        measurably better performance), by reverting commit
        69a37bea.
      Requested-by: NJeremy Eder <jeder@redhat.com>
      Tested-by: NLen Brown <len.brown@intel.com>
      Cc: 3.8+ <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      14851912
    • R
      Revert "cpuidle: Quickly notice prediction failure in general case" · 228b3023
      Rafael J. Wysocki 提交于
      Revert commit e11538d1 (cpuidle: Quickly notice prediction failure in
      general case), since it depends on commit 69a37bea (cpuidle: Quickly
      notice prediction failure for repeat mode) that has been identified
      as the source of a significant performance regression in v3.8 and
      later.
      Requested-by: NJeremy Eder <jeder@redhat.com>
      Tested-by: NLen Brown <len.brown@intel.com>
      Cc: 3.8+ <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      228b3023
  9. 27 7月, 2013 2 次提交
  10. 15 7月, 2013 7 次提交
  11. 24 6月, 2013 1 次提交
  12. 11 6月, 2013 3 次提交
    • D
      cpuidle: Fix ARCH_NEEDS_CPU_IDLE_COUPLED dependency warning · b39b0981
      Daniel Lezcano 提交于
      Before commit d6f346f2 (cpuidle: improve governor Kconfig options),
      the CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED option didn't depend on
      CONFIG_CPU_IDLE but now it has been moved under the CPU_IDLE
      menuconfig.
      
      That raises the following warnings:
      
       warning: (ARCH_OMAP4 && ARCH_TEGRA_2x_SOC) selects ARCH_NEEDS_CPU_IDLE_COUPLED
       which has unmet direct dependencies (CPU_IDLE)
       warning: (ARCH_OMAP4 && ARCH_TEGRA_2x_SOC) selects ARCH_NEEDS_CPU_IDLE_COUPLED
       which has unmet direct dependencies (CPU_IDLE)
      
      because the tegra2 and omap4 Kconfig files select this option
      without checking if CPU_IDLE is set.
      
      Fix that by moving ARCH_NEEDS_CPU_IDLE_COUPLED outside of CPU_IDLE.
      
      [rjw: Changelog]
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b39b0981
    • D
      cpuidle: Comment the driver's framework code · 6d19cb93
      Daniel Lezcano 提交于
      Add kerneldoc (and other) comments to the cpuidle driver's framework
      code.
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6d19cb93
    • D
      cpuidle: simplify multiple driver support · 82467a5a
      Daniel Lezcano 提交于
      Commit bf4d1b5d (cpuidle: support multiple drivers) introduced support
      for using multiple cpuidle drivers at the same time.  It added a
      couple of new APIs to register the driver per CPU, but that led to
      some unnecessary code complexity related to the kernel config options
      deciding whether or not the multiple driver support is enabled.  The
      code has to work as it did before when the multiple driver support is
      not enabled and the multiple driver support has to be compatible with
      the previously existing API.
      
      Remove the new API, not used by any driver in the tree yet (but
      needed for the HMP cpuidle drivers that will be submitted soon), and
      add a new cpumask pointer to the cpuidle driver structure that will
      point to the mask of CPUs handled by the given driver.  That will
      allow the cpuidle_[un]register_driver() API to be used for the
      multiple driver support along with the cpuidle_[un]register()
      functions added recently.
      
      [rjw: Changelog]
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      82467a5a
  13. 05 6月, 2013 1 次提交
  14. 04 6月, 2013 1 次提交
    • D
      cpuidle: improve governor Kconfig options · d6f346f2
      Daniel Lezcano 提交于
      Each governor is suitable for different kernel configurations: the menu
      governor suits better for a tickless system, while the ladder governor fits
      better for a periodic timer tick system.
      
      The Kconfig does not allow to [un]select a governor, thus both are compiled in
      the kernel but the init order makes the menu governor to be the last one to be
      registered, so becoming the default. The only way to switch back to the ladder
      governor is to enable the sysfs governor switch in the kernel command line.
      
      Because it seems nobody complained about this, the menu governor is used by
      default most of the time on the system, having both governors is not really
      necessary on a tickless system but there isn't a config option to disable one
      or another governor.
      
      Create a submenu for cpuidle and add a label for each governor, so we can see
      the option in the menu config and enable/disable it.
      
      The governors will be enabled depending on the CONFIG_NO_HZ option:
       - If CONFIG_NO_HZ is set, then the menu governor is selected and the ladder
         governor is optional, defaulting to 'yes'
       - If CONFIG_NO_HZ is not set, then the ladder governor is selected and the
         menu governor is optional, defaulting to 'yes'
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d6f346f2
  15. 30 5月, 2013 1 次提交
  16. 27 4月, 2013 1 次提交
    • D
      cpuidle: add maintainer entry · a8e39c35
      Daniel Lezcano 提交于
      Currently cpuidle drivers are spread across different archs.
      
      As a result, there are several different paths for cpuidle patch
      submissions: cpuidle core changes go through linux-pm, ARM driver
      changes go to the arm-soc or SoC-specific trees, sh changes go
      through the sh arch tree, pseries changes go through the PowerPC tree
      and finally intel changes go through the Len's tree while ACPI idle
      changes go through linux-pm.
      
      That makes it difficult to consolidate code and to propagate
      modifications from the cpuidle core to the different drivers.
      
      Hopefully, a movement has started to put the majority of cpuidle
      drivers under drivers/cpuidle like cpuidle-calxeda.c and
      cpuidle-kirkwood.c.
      
      Add a maintainer entry for cpuidle to MAINTAINERS to clarify the
      situation and to indicate to new cpuidle driver authors that those
      drivers should not go into arch-specific directories.
      
      The upstreaming process is unchanged: Rafael takes patches for
      merging into his tree, but with an Acked-by: tag from the driver's
      maintainer, so indicate in the drivers' headers who maintains them.
      
      The arrangement will be the same as for cpufreq.
      
      [rjw: Changelog]
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: Andrew Lunn <andrew@lunn.ch>  #for kirkwood
      Acked-by: Jason Cooper <jason@lakedaemon.net> #for kirkwood
      Acked-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a8e39c35
  17. 24 4月, 2013 1 次提交
  18. 23 4月, 2013 2 次提交