20 Dec, 2011

1 commit


15 Dec, 2011

1 commit


06 Dec, 2011

1 commit

  • This patch changes fields in cpustat from a structure, to an
    u64 array. Math gets easier, and the code is more flexible.

    Signed-off-by: Glauber Costa
    Reviewed-by: KAMEZAWA Hiroyuki
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Cc: Paul Tuner
    Signed-off-by: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1322498719-2255-2-git-send-email-glommer@parallels.com
    Signed-off-by: Ingo Molnar

    Glauber Costa
     

08 Sep, 2011

1 commit

  • update_ts_time_stat currently updates idle time even if we are in
    iowait loop at the moment. The only real users of the idle counter
    (via get_cpu_idle_time_us) are CPU governors and they expect to get
    cumulative time for both idle and iowait times.
    The value (idle_sleeptime) is also printed to userspace by print_cpu
    but it prints both idle and iowait times so the idle part is misleading.

    Let's clean this up and fix update_ts_time_stat to account both counters
    properly and update consumers of idle to consider iowait time as well.
    If we do this we might use get_cpu_{idle,iowait}_time_us from other
    contexts as well and we will get expected values.

    Signed-off-by: Michal Hocko
    Cc: Dave Jones
    Cc: Arnd Bergmann
    Cc: Alexey Dobriyan
    Link: http://lkml.kernel.org/r/e9c909c221a8da402c4da07e4cd968c3218f8eb1.1314172057.git.mhocko@suse.cz
    Signed-off-by: Thomas Gleixner

    Michal Hocko
     

17 Mar, 2011

4 commits


26 Jan, 2011

1 commit

  • With cmwq, there's no reason for cpufreq drivers to use separate
    workqueues. Remove the dedicated workqueues from cpufreq_conservative
    and cpufreq_ondemand and use system_wq instead. The work items are
    already sync canceled on stop, so it's already guaranteed that no work
    is running on module exit.

    Signed-off-by: Tejun Heo
    Acked-by: Dave Jones
    Cc: cpufreq@vger.kernel.org

    Tejun Heo
     

09 May, 2010

1 commit


10 Apr, 2010

1 commit

  • Multiple modules used to define those which are with identical
    functionality and were needlessly replicated among the different cpufreq
    drivers. Push them into the header and remove duplication.

    Signed-off-by: Borislav Petkov
    LKML-Reference:
    Reviewed-by: Thomas Renninger
    Signed-off-by: H. Peter Anvin

    Borislav Petkov
     

01 Apr, 2010

1 commit


25 Nov, 2009

1 commit


18 Nov, 2009

1 commit

  • ondemand and conservative governors are messing up time units in the
    code path where NO_HZ is not enabled and ignore_nice is set. The walltime
    idletime stored is in jiffies and nice time calculation is happening in
    microseconds.

    The problem was reported and diagnosed by Alexander here.
    http://marc.info/?l=linux-kernel&m=125752550404513&w=2

    The patch below fixes this thinko.

    Reported-by: Alexander Miller
    Tested-by: Alexander Miller
    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Dave Jones

    Pallipadi, Venkatesh
     

14 Aug, 2009

1 commit

  • Conflicts:
    arch/sparc/kernel/smp_64.c
    arch/x86/kernel/cpu/perf_counter.c
    arch/x86/kernel/setup_percpu.c
    drivers/cpufreq/cpufreq_ondemand.c
    mm/percpu.c

    Conflicts in core and arch percpu codes are mostly from commit
    ed78e1e078dd44249f88b1dd8c76dafb39567161 which substituted many
    num_possible_cpus() with nr_cpu_ids. As for-next branch has moved all
    the first chunk allocators into mm/percpu.c, the changes are moved
    from arch code to mm/percpu.c.

    Signed-off-by: Tejun Heo

    Tejun Heo
     

05 Aug, 2009

1 commit

  • Commit ee88415caf736b89500f16e0a545614541a45005
    introduced this regression when it removed enable bit in cpu_dbs_info_s.
    That added a possibility of dbs_cpufreq_notifier getting called for a
    CPU that is not yet managed by conservative governor. That will happen
    as the transition notifier is set as soon as one CPU switches to
    conservative governor and other CPUs can get a NULL pointer dereference
    without the enable bit check. Add the enable bit back again.

    Reported-by: Lermytte Christophe
    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Dave Jones

    Pallipadi, Venkatesh
     

07 Jul, 2009

2 commits

  • Redesign the locking inside conservative driver. Make dbs_mutex handle all the
    global state changes inside the driver and invent a new percpu mutex
    to serialize percpu timer and frequency limit change.

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Dave Jones

    venkatesh.pallipadi@intel.com
     
  • Commit b14893a62c73af0eca414cfed505b8c09efc613c although it was very
    much needed to properly cleanup ondemand timer, opened-up a can of worms
    related to locking dependencies in cpufreq.

    Patch here defines the need for dbs_mutex and cleans up its usage in
    ondemand governor. This also resolves the lockdep warnings reported here

    http://lkml.indiana.edu/hypermail/linux/kernel/0906.1/01925.html
    http://lkml.indiana.edu/hypermail/linux/kernel/0907.0/00820.html

    and few others..

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Dave Jones

    venkatesh.pallipadi@intel.com
     

24 Jun, 2009

1 commit

  • Percpu variable definition is about to be updated such that all percpu
    symbols including the static ones must be unique. Update percpu
    variable definitions accordingly.

    * as,cfq: rename ioc_count uniquely

    * cpufreq: rename cpu_dbs_info uniquely

    * xen: move nesting_count out of xen_evtchn_do_upcall() and rename it

    * mm: move ratelimits out of balance_dirty_pages_ratelimited_nr() and
    rename it

    * ipv4,6: rename cookie_scratch uniquely

    * x86 perf_counter: rename prev_left to pmc_prev_left, irq_entry to
    pmc_irq_entry and nmi_entry to pmc_nmi_entry

    * perf_counter: rename disable_count to perf_disable_count

    * ftrace: rename test_event_disable to ftrace_test_event_disable

    * kmemleak: rename test_pointer to kmemleak_test_pointer

    * mce: rename next_interval to mce_next_interval

    [ Impact: percpu usage cleanups, no duplicate static percpu var names ]

    Signed-off-by: Tejun Heo
    Reviewed-by: Christoph Lameter
    Cc: Ivan Kokshaysky
    Cc: Jens Axboe
    Cc: Dave Jones
    Cc: Jeremy Fitzhardinge
    Cc: linux-mm
    Cc: David S. Miller
    Cc: Peter Zijlstra
    Cc: Steven Rostedt
    Cc: Li Zefan
    Cc: Catalin Marinas
    Cc: Andi Kleen

    Tejun Heo
     

15 Jun, 2009

2 commits

  • Update the documentation accordingly.
    Cleanup and use printk_once.

    Signed-off-by: Thomas Renninger
    Signed-off-by: Dave Jones

    Thomas Renninger
     
  • With this patch you have following minimal sampling rate restrictions:

    Kernel restrictions:
    If CONFIG_NO_HZ is set, the limit is 10ms fixed.
    If CONFIG_NO_HZ is not set or no_hz=off boot parameter is used, the
    limits depend on the CONFIG_HZ option:
    HZ=1000: min=20000us (20ms)
    HZ=250: min=80000us (80ms)
    HZ=100: min=200000us (200ms)

    HW restrictions:
    Do not sample/poll more often than HW latency * 100 exported by the low
    level cpufreq HW driver

    The higher value of above restrictions is the minimal sampling rate
    that can be set (and can be seen via ondemand/sampling_rate_min sysfs file)

    Default sampling rate still is HW latency * 1000, but this will now end
    up in lower values on latest (Intel and AMD) hardware as these can switch
    really fast and sampling rate mostly was limited to the 80ms or 200ms
    (depending on whether HZ=250 or HZ=1000 is used).

    Signed-off-by: Thomas Renninger
    Cc: Pallipadi Venkatesh
    Signed-off-by: Dave Jones

    Thomas Renninger
     

27 May, 2009

1 commit

  • * Rafael J. Wysocki (rjw@sisk.pl) wrote:
    > This message has been generated automatically as a part of a report
    > of regressions introduced between 2.6.28 and 2.6.29.
    >
    > The following bug entry is on the current list of known regressions
    > introduced between 2.6.28 and 2.6.29. Please verify if it still should
    > be listed and let me know (either way).
    >
    >
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13186
    > Subject : cpufreq timer teardown problem
    > Submitter : Mathieu Desnoyers
    > Date : 2009-04-23 14:00 (24 days old)
    > References : http://marc.info/?l=linux-kernel&m=124049523515036&w=4
    > Handled-By : Mathieu Desnoyers
    > Patch : http://patchwork.kernel.org/patch/19754/
    > http://patchwork.kernel.org/patch/19753/
    >

    (re-send with updated changelog)

    cpufreq fix timer teardown in conservative governor

    The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
    use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
    workqueue handler to exit.

    The ondemand governor does not seem to be affected because the
    "if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
    immediately without rescheduling the work. The conservative governor in
    2.6.30-rc has the same check as the ondemand governor, which makes things
    usually run smoothly. However, if the governor is quickly stopped and then
    started, this could lead to the following race :

    dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
    This is why a synchronized teardown is required.

    Depends on patch
    cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call

    The following patch applies to 2.6.30-rc2. Stable kernels have a similar
    issue which should also be fixed, but the code changed between 2.6.29
    and 2.6.30, so this patch only applies to 2.6.30-rc.

    Signed-off-by: Mathieu Desnoyers
    CC: Andrew Morton
    CC: gregkh@suse.de
    CC: stable@kernel.org
    CC: cpufreq@vger.kernel.org
    CC: Ingo Molnar
    CC: rjw@sisk.pl
    CC: Ben Slusky
    Signed-off-by: Dave Jones

    Mathieu Desnoyers
     

25 Feb, 2009

7 commits


06 Jan, 2009

1 commit

  • Impact: use new cpumask API to reduce memory usage

    This is part of an effort to reduce structure sizes for machines
    configured with large NR_CPUS. cpumask_t gets replaced by
    cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or
    struct cpumask * (large NR_CPUS).

    Signed-off-by: Rusty Russell
    Signed-off-by: Mike Travis
    Acked-by: Dave Jones
    Signed-off-by: Ingo Molnar

    Rusty Russell
     

10 Oct, 2008

2 commits

  • We don't need to export the governors for use as the default governor,
    because the default governor will be built-in anyway and we can access
    the symbol directly.

    This also fixes the following sparse warnings:

    drivers/cpufreq/cpufreq_conservative.c:578:25: warning: symbol 'cpufreq_gov_conservative' was not declared. Should it be static?
    drivers/cpufreq/cpufreq_ondemand.c:582:25: warning: symbol 'cpufreq_gov_ondemand' was not declared. Should it be static?
    drivers/cpufreq/cpufreq_performance.c:39:25: warning: symbol 'cpufreq_gov_performance' was not declared. Should it be static?
    drivers/cpufreq/cpufreq_powersave.c:38:25: warning: symbol 'cpufreq_gov_powersave' was not declared. Should it be static?
    drivers/cpufreq/cpufreq_userspace.c:190:25: warning: symbol 'cpufreq_gov_userspace' was not declared. Should it be static?

    Signed-off-by: Sven Wegener
    Signed-off-by: Dave Jones

    Sven Wegener
     
  • Venki Pallipadi made a similar change to the ondemand governor a while
    back (in commit 28287033e12463c8ff89f1ea8038783d0360391c). It seems to
    work just as well in the conservative governor, leading to fewer wakeups
    as reported by powertop.

    Signed-off-by: Ben Slusky
    Signed-off-by: Dave Jones

    Ben Slusky
     

09 Aug, 2008

1 commit


24 May, 2008

1 commit


18 Jan, 2008

1 commit

  • When the cpufreq driver starts up at boot time, it calls into the default
    governor which might not be initialised yet. This hurts when the
    governor's worker function relies on memory that is not yet set up by its
    init function.

    This migrates all governors from module_init() to fs_initcall() when being
    the default, as was already done in cpufreq_performance when it was the
    only possible choice. The performance governor is always initialized early
    because it might be used as fallback even when not being the default.

    Fixes at least one actual oops where ondemand is the default governor and
    cpufreq_governor_dbs() uses the uninitialised kondemand_wq work-queue
    during boot-time.

    Signed-off-by: Johannes Weiner
    Cc: Dave Jones
    Cc: "Rafael J. Wysocki"
    Cc: Venkatesh Pallipadi
    Acked-by: Ingo Molnar
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Johannes Weiner
     

23 Oct, 2007

2 commits


05 Oct, 2007

1 commit

  • Depending on the transition latency of the HW for cpufreq switches, the
    ondemand or conservative governor cannot be used with certain cpufreq
    drivers. Still the ondemand should be the default governor on a wide range
    of systems. This patch allows this and lets the governor fallback to the
    performance governor at cpufreq driver load time, if the driver does not
    support fast enough frequency switching.

    Main benefit is that on e.g. installation or other systems without
    userspace support a working dynamic cpufreq support can be achieved on most
    systems by simply loading the cpufreq driver. This is especially essential
    for recent x86(_64) laptop hardware which may rely on working dynamic
    cpufreq OS support.

    Signed-off-by: Thomas Renninger
    Signed-off-by: Venkatesh Pallipadi
    Cc: Russell King
    Cc: Bryan Wu
    Cc: Andi Kleen
    Cc: "Luck, Tony"
    Cc: Paul Mackerras
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mundt
    Cc: "David S. Miller"
    Signed-off-by: Andrew Morton
    Signed-off-by: Dave Jones

    Thomas Renninger
     

17 Feb, 2007

1 commit

  • * master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq:
    [CPUFREQ] Longhaul - Redo Longhaul ver. 2
    [CPUFREQ] EPS - Correct 2nd brand test
    [CPUFREQ] Longhaul - Separate frequency and voltage transition
    [CPUFREQ] Longhaul - Models of Nehemiah
    [CPUFREQ] Whitespace fixup
    [CPUFREQ] Longhaul - Simplier minmult
    [CPUFREQ] CPU_FREQ_TABLE shouldn't be a def_tristate
    [CPUFREQ] ondemand governor use new cpufreq rwsem locking in work callback
    [CPUFREQ] ondemand governor restructure the work callback
    [CPUFREQ] Rewrite lock in cpufreq to eliminate cpufreq/hotplug related issues
    [CPUFREQ] Remove hotplug cpu crap
    [CPUFREQ] Enhanced PowerSaver driver
    [CPUFREQ] Longhaul - Add VT8235 support
    [CPUFREQ] Longhaul - Fix guess_fsb function
    [CPUFREQ] Longhaul - Remove duplicate tables
    [CPUFREQ] Longhaul - Introduce Nehemiah C
    [CPUFREQ] fix cpuinfo_cur_freq for CPU_HW_PSTATE
    [CPUFREQ] Longhaul - Remove "ignore_latency" option

    Linus Torvalds
     

15 Feb, 2007

1 commit

  • After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau