1. 19 Jun, 2019 1 commit
  2. 09 Apr, 2019 1 commit
  3. 01 Feb, 2019 2 commits
  4. 05 Jan, 2018 1 commit
  5. 08 Nov, 2017 1 commit
  6. 04 Jul, 2017 1 commit
  7. 28 May, 2017 1 commit
  8. 03 Feb, 2017 1 commit
  9. 01 Feb, 2017 1 commit
    • Frederic Weisbecker's avatar
      sched/cputime: Convert kcpustat to nsecs · 7fb1327e
      Frederic Weisbecker authored
      Kernel CPU stats are stored in cputime_t which is an architecture
      defined type, and hence a bit opaque and requiring accessors and mutators
      for any operation.
      
      Converting them to nsecs simplifies the code and is one step toward
      the removal of cputime_t in the core code.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Stanislaw Gruszka <sgruszka@redhat.com>
      Cc: Wanpeng Li <wanpeng.li@hotmail.com>
      Link: http://lkml.kernel.org/r/1485832191-26889-4-git-send-email-fweisbec@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7fb1327e
  10. 11 Nov, 2016 1 commit
  11. 08 Jun, 2016 1 commit
    • Viresh Kumar's avatar
      cpufreq: Remove cpufreq_frequency_get_table() · f8bfc116
      Viresh Kumar authored
      Most of the callers of cpufreq_frequency_get_table() already have the
      pointer to a valid 'policy' structure and they don't really need to go
      through the per-cpu variable first and then a check to validate the
      frequency, in order to find the freq-table for the policy.
      
      Directly use the policy->freq_table field instead for them.
      
      Only one user of that API is left after above changes, cpu_cooling.c and
      it accesses the freq_table in a racy way as the policy can get freed in
      between.
      
      Fix it by using cpufreq_cpu_get() properly.
      
      Since there are no more users of cpufreq_frequency_get_table() left, get
      rid of it.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: Javi Merino <javi.merino@arm.com> (cpu_cooling.c)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f8bfc116
  12. 02 Jun, 2016 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: stats: Make the stats code non-modular · 1aefc75b
      Rafael J. Wysocki authored
      The modularity of cpufreq_stats is quite problematic.
      
      First off, the usage of policy notifiers for the initialization
      and cleanup in the cpufreq_stats module is inherently racy with
      respect to CPU offline/online and the initialization and cleanup
      of the cpufreq driver.
      
      Second, fast frequency switching (used by the schedutil governor)
      cannot be enabled if any transition notifiers are registered, so
      if the cpufreq_stats module (that registers a transition notifier
      for updating transition statistics) is loaded, the schedutil governor
      cannot use fast frequency switching.
      
      On the other hand, allowing cpufreq_stats to be built as a module
      doesn't really add much value.  Arguably, there's not much reason
      for that code to be modular at all.
      
      For the above reasons, make the cpufreq stats code non-modular,
      modify the core to invoke functions provided by that code directly
      and drop the notifiers from it.
      
      Make the stats sysfs attributes appear empty if fast frequency
      switching is enabled as the statistics will not be updated in that
      case anyway (and returning -EBUSY from those attributes breaks
      powertop).
      
      While at it, clean up Kconfig help for the CPU_FREQ_STAT and
      CPU_FREQ_STAT_DETAILS options.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      1aefc75b
  13. 23 Jan, 2015 14 commits
  14. 29 Apr, 2014 1 commit
  15. 13 Mar, 2014 1 commit
    • Frederic Weisbecker's avatar
      cputime: Default implementation of nsecs -> cputime conversion · bfc3f028
      Frederic Weisbecker authored
      The architectures that override cputime_t (s390, ppc) don't provide
      any version of nsecs_to_cputime(). Indeed this cputime_t implementation
      by backend only happens when CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y under
      which the core code doesn't make any use of nsecs_to_cputime().
      
      At least for now.
      
      We are going to make a broader use of it so lets provide a default
      version with a per usecs granularity. It should be good enough for most
      usecases.
      
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      bfc3f028
  16. 01 Mar, 2014 3 commits
  17. 17 Jan, 2014 4 commits
    • Viresh Kumar's avatar
      cpufreq: stats: create sysfs entries when cpufreq_stats is a module · b3f9ff88
      Viresh Kumar authored
      When cpufreq_stats is compiled in as a module, cpufreq driver would
      have already been registered. And so the CPUFREQ_CREATE_POLICY
      notifiers wouldn't be called for it. Hence no sysfs entries for stats. :(
      
      This patch calls cpufreq_stats_create_table() for each online CPU from
      cpufreq_stats_init() and so if policy is already created for CPUx then
      we will register sysfs stats for it.
      
      When its not compiled as module, we will return early as policy wouldn't
      be found for any of the CPUs.
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Tested-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b3f9ff88
    • Viresh Kumar's avatar
      cpufreq: stats: free table and remove sysfs entry in a single routine · 2d13594d
      Viresh Kumar authored
      We don't have code paths now where we need to do these two things
      separately, so it is better do them in a single routine. Just as
      they are allocated in a single routine.
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Tested-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2d13594d
    • Viresh Kumar's avatar
      cpufreq: stats: remove hotplug notifiers · 027cc2e4
      Viresh Kumar authored
      Either CPUs are hot-unplugged or suspend/resume occurs, cpufreq core
      will send notifications to cpufreq-stats and stats structure and sysfs
      entries would be correctly handled..
      
      And so we don't actually need hotcpu notifiers in cpufreq-stats anymore.
      We were only handling cpu hot-unplug events here and that are already
      taken care of by POLICY notifiers.
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Tested-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      027cc2e4
    • Viresh Kumar's avatar
      cpufreq: stats: handle cpufreq_unregister_driver() and suspend/resume properly · fcd7af91
      Viresh Kumar authored
      There are several problems with cpufreq stats in the way it handles
      cpufreq_unregister_driver() and suspend/resume..
      
       - We must not lose data collected so far when suspend/resume happens
         and so stats directories must not be removed/allocated during these
         operations, which is done currently.
      
       - cpufreq_stat has registered notifiers with both cpufreq and hotplug.
         It adds sysfs stats directory with a cpufreq notifier: CPUFREQ_NOTIFY
         and removes this directory with a notifier from hotplug core.
      
         In case cpufreq_unregister_driver() is called (on rmmod cpufreq driver),
         stats directories per cpu aren't removed as CPUs are still online. The
         only call cpufreq_stats gets is cpufreq_stats_update_policy_cpu() for
         all CPUs except the last of each policy. And pointer to stat information
         is stored in the entry for last CPU in the per-cpu cpufreq_stats_table.
         But policy structure would be freed inside cpufreq core and so that will
         result in memory leak inside cpufreq stats (as we are never freeing
         memory for stats).
      
         Now if we again insert the module cpufreq_register_driver() will be
         called and we will again allocate stats data and put it on for first
         CPU of every policy.  In case we only have a single CPU per policy, we
         will return with a error from cpufreq_stats_create_table() due to this
         code:
      
      	if (per_cpu(cpufreq_stats_table, cpu))
      		return -EBUSY;
      
         And so probably cpufreq stats directory would not show up anymore (as
         it was added inside last policies->kobj which doesn't exist anymore).
         I haven't tested it, though. Also the values in stats files wouldn't
         be refreshed as we are using the earlier stats structure.
      
       - CPUFREQ_NOTIFY is called from cpufreq_set_policy() which is called for
         scenarios where we don't really want cpufreq_stat_notifier_policy() to get
         called. For example whenever we are changing anything related to a policy:
         min/max/current freq, etc. cpufreq_set_policy() is called and so cpufreq
         stats is notified. Where we don't do any useful stuff other than simply
         returning with -EBUSY from cpufreq_stats_create_table(). And so this
         isn't the right notifier that cpufreq stats..
      
       Due to all above reasons this patch does following changes:
       - Add new notifiers CPUFREQ_CREATE_POLICY and CPUFREQ_REMOVE_POLICY,
         which are only called when policy is created/destroyed. They aren't
         called for suspend/resume paths..
       - Use these notifiers in cpufreq_stat_notifier_policy() to create/destory
         stats sysfs entries. And so cpufreq_unregister_driver() or suspend/resume
         shouldn't be a problem for cpufreq_stats.
       - Return early from cpufreq_stat_cpu_callback() for suspend/resume sequence,
         so that we don't free stats structure.
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Tested-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fcd7af91
  18. 10 Sep, 2013 1 commit
    • Andreas Schwab's avatar
      cpufreq: Fix wrong time unit conversion · a857c0b9
      Andreas Schwab authored
      The time spent by a CPU under a given frequency is stored in jiffies unit
      in the cpu var cpufreq_stats_table->time_in_state[i], i being the index of
      the frequency.
      
      This is what is displayed in the following file on the right column:
      
           cat /sys/devices/system/cpu/cpuX/cpufreq/stats/time_in_state
           2301000 19835820
           2300000 3172
           [...]
      
      Now cpufreq converts this jiffies unit delta to clock_t before returning it
      to the user as in the above file. And that conversion is achieved using the API
      cputime64_to_clock_t().
      
      Although it accidentally works on traditional tick based cputime accounting, where
      cputime_t maps directly to jiffies, it doesn't work with other types of cputime
      accounting such as CONFIG_VIRT_CPU_ACCOUNTING_* where cputime_t can map to nsecs
      or any granularity preffered by the architecture.
      
      For example we get a buggy zero delta on full dyntick configurations:
      
           cat /sys/devices/system/cpu/cpuX/cpufreq/stats/time_in_state
           2301000 0
           2300000 0
           [...]
      
      Fix this with using the proper jiffies_64_t to clock_t conversion.
      Reported-and-tested-by: default avatarCarsten Emde <C.Emde@osadl.org>
      Signed-off-by: default avatarAndreas Schwab <schwab@linux-m68k.org>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a857c0b9
  19. 07 Aug, 2013 3 commits