20 Mar, 2014

1 commit

  • Recommend the usage of the new CPU hotplug callback registration APIs
    (__register_cpu_notifier() etc), when subsystems need to also perform
    initialization for already online CPUs. Provide examples of correct
    and race-free ways of achieving this, and point out the kinds of code
    that are error-prone.

    Cc: Rob Landley
    Cc: Ingo Molnar
    Signed-off-by: Srivatsa S. Bhat
    Signed-off-by: Rafael J. Wysocki

    Srivatsa S. Bhat
     

24 Jan, 2014

1 commit


13 Nov, 2013

1 commit

  • Zwane Mwaikambo's @arm.linux.org.uk address no longer works. In February
    2013 he asked for his gmail address to be used instead [1] so let's just
    do that.

    [1] http://marc.info/?l=linux-kernel&m=136079068903214&w=2

    Signed-off-by: Jean Delvare
    Cc: Russell King
    Cc: Zwane Mwaikambo
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     

15 Jul, 2013

1 commit

  • The __cpuinit type of throwaway sections might have made sense
    some time ago when RAM was more constrained, but now the savings
    do not offset the cost and complications. For example, the fix in
    commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
    is a good example of the nasty type of bugs that can be created
    with improper use of the various __init prefixes.

    After a discussion on LKML[1] it was decided that cpuinit should go
    the way of devinit and be phased out. Once all the users are gone,
    we can then finally remove the macros themselves from linux/init.h.

    This removes all the uses of the __cpuinit macros from C files in
    the core kernel directories (kernel, init, lib, mm, and include)
    that don't really have a specific maintainer.

    [1] https://lkml.org/lkml/2013/5/20/589

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

04 Jul, 2013

1 commit

  • Pull power management and ACPI updates from Rafael Wysocki:
    "This time the total number of ACPI commits is slightly greater than
    the number of cpufreq commits, but Viresh Kumar (who works on cpufreq)
    remains the most active patch submitter.

    To me, the most significant change is the addition of offline/online
    device operations to the driver core (with the Greg's blessing) and
    the related modifications of the ACPI core hotplug code. Next are the
    freezer updates from Colin Cross that should make the freezing of
    tasks a bit less heavy weight.

    We also have a couple of regression fixes, a number of fixes for
    issues that have not been identified as regressions, two new drivers
    and a bunch of cleanups all over.

    Highlights:

    - Hotplug changes to support graceful hot-removal failures.

    It sometimes is necessary to fail device hot-removal operations
    gracefully if they cannot be carried out completely. For example,
    if memory from a memory module being hot-removed has been allocated
    for the kernel's own use and cannot be moved elsewhere, it's
    desirable to fail the hot-removal operation in a graceful way
    rather than to crash the kernel, but currenty a success or a kernel
    crash are the only possible outcomes of an attempted memory
    hot-removal. Needless to say, that is not a very attractive
    alternative and it had to be addressed.

    However, in order to make it work for memory, I first had to make
    it work for CPUs and for this purpose I needed to modify the ACPI
    processor driver. It's been split into two parts, a resident one
    handling the low-level initialization/cleanup and a modular one
    playing the actual driver's role (but it binds to the CPU system
    device objects rather than to the ACPI device objects representing
    processors). That's been sort of like a live brain surgery on a
    patient who's riding a bike.

    So this is a little scary, but since we found and fixed a couple of
    regressions it caused to happen during the early linux-next testing
    (a month ago), nobody has complained.

    As a bonus we remove some duplicated ACPI hotplug code, because the
    ACPI-based CPU hotplug is now going to use the common ACPI hotplug
    code.

    - Lighter weight freezing of tasks.

    These changes from Colin Cross and Mandeep Singh Baines are
    targeted at making the freezing of tasks a bit less heavy weight
    operation. They reduce the number of tasks woken up every time
    during the freezing, by using the observation that the freezer
    simply doesn't need to wake up some of them and wait for them all
    to call refrigerator(). The time needed for the freezer to decide
    to report a failure is reduced too.

    Also reintroduced is the check causing a lockdep warining to
    trigger when try_to_freeze() is called with locks held (which is
    generally unsafe and shouldn't happen).

    - cpufreq updates

    First off, a commit from Srivatsa S Bhat fixes a resume regression
    introduced during the 3.10 cycle causing some cpufreq sysfs
    attributes to return wrong values to user space after resume. The
    fix is kind of fresh, but also it's pretty obvious once Srivatsa
    has identified the root cause.

    Second, we have a new freqdomain_cpus sysfs attribute for the
    acpi-cpufreq driver to provide information previously available via
    related_cpus. From Lan Tianyu.

    Finally, we fix a number of issues, mostly related to the
    CPUFREQ_POSTCHANGE notifier and cpufreq Kconfig options and clean
    up some code. The majority of changes from Viresh Kumar with bits
    from Jacob Shin, Heiko Stübner, Xiaoguang Chen, Ezequiel Garcia,
    Arnd Bergmann, and Tang Yuantian.

    - ACPICA update

    A usual bunch of updates from the ACPICA upstream.

    During the 3.4 cycle we introduced support for ACPI 5 extended
    sleep registers, but they are only supposed to be used if the
    HW-reduced mode bit is set in the FADT flags and the code attempted
    to use them without checking that bit. That caused suspend/resume
    regressions to happen on some systems. Fix from Lv Zheng causes
    those registers to be used only if the HW-reduced mode bit is set.

    Apart from this some other ACPICA bugs are fixed and code cleanups
    are made by Bob Moore, Tomasz Nowicki, Lv Zheng, Chao Guan, and
    Zhang Rui.

    - cpuidle updates

    New driver for Xilinx Zynq processors is added by Michal Simek.

    Multidriver support simplification, addition of some missing
    kerneldoc comments and Kconfig-related fixes come from Daniel
    Lezcano.

    - ACPI power management updates

    Changes to make suspend/resume work correctly in Xen guests from
    Konrad Rzeszutek Wilk, sparse warning fix from Fengguang Wu and
    cleanups and fixes of the ACPI device power state selection
    routine.

    - ACPI documentation updates

    Some previously missing pieces of ACPI documentation are added by
    Lv Zheng and Aaron Lu (hopefully, that will help people to
    uderstand how the ACPI subsystem works) and one outdated doc is
    updated by Hanjun Guo.

    - Assorted ACPI updates

    We finally nailed down the IA-64 issue that was the reason for
    reverting commit 9f29ab11ddbf ("ACPI / scan: do not match drivers
    against objects having scan handlers"), so we can fix it and move
    the ACPI scan handler check added to the ACPI video driver back to
    the core.

    A mechanism for adding CMOS RTC address space handlers is
    introduced by Lan Tianyu to allow some EC-related breakage to be
    fixed on some systems.

    A spec-compliant implementation of acpi_os_get_timer() is added by
    Mika Westerberg.

    The evaluation of _STA is added to do_acpi_find_child() to avoid
    situations in which a pointer to a disabled device object is
    returned instead of an enabled one with the same _ADR value. From
    Jeff Wu.

    Intel BayTrail PCH (Platform Controller Hub) support is added to
    the ACPI driver for Intel Low-Power Subsystems (LPSS) and that
    driver is modified to work around a couple of known BIOS issues.
    Changes from Mika Westerberg and Heikki Krogerus.

    The EC driver is fixed by Vasiliy Kulikov to use get_user() and
    put_user() instead of dereferencing user space pointers blindly.

    Code cleanups are made by Bjorn Helgaas, Nicholas Mazzuca and Toshi
    Kani.

    - Assorted power management updates

    The "runtime idle" helper routine is changed to take the return
    values of the callbacks executed by it into account and to call
    rpm_suspend() if they return 0, which allows us to reduce the
    overall code bloat a bit (by dropping some code that's not
    necessary any more after that modification).

    The runtime PM documentation is updated by Alan Stern (to reflect
    the "runtime idle" behavior change).

    New trace points for PM QoS are added by Sahara
    ().

    PM QoS documentation is updated by Lan Tianyu.

    Code cleanups are made and minor issues are addressed by Bernie
    Thompson, Bjorn Helgaas, Julius Werner, and Shuah Khan.

    - devfreq updates

    New driver for the Exynos5-bus device from Abhilash Kesavan.

    Minor cleanups, fixes and MAINTAINERS update from MyungJoo Ham,
    Abhilash Kesavan, Paul Bolle, Rajagopal Venkat, and Wei Yongjun.

    - OMAP power management updates

    Adaptive Voltage Scaling (AVS) SmartReflex voltage control driver
    updates from Andrii Tseglytskyi and Nishanth Menon."

    * tag 'pm+acpi-3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (162 commits)
    cpufreq: Fix cpufreq regression after suspend/resume
    ACPI / PM: Fix possible NULL pointer deref in acpi_pm_device_sleep_state()
    PM / Sleep: Warn about system time after resume with pm_trace
    cpufreq: don't leave stale policy pointer in cdbs->cur_policy
    acpi-cpufreq: Add new sysfs attribute freqdomain_cpus
    cpufreq: make sure frequency transitions are serialized
    ACPI: implement acpi_os_get_timer() according the spec
    ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan
    ACPI: Add CMOS RTC Operation Region handler support
    ACPI / processor: Drop unused variable from processor_perflib.c
    cpufreq: tegra: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: s3c64xx: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: omap: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: imx6q: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: exynos: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: dbx500: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: davinci: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: arm-big-little: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: powernow-k8: call CPUFREQ_POSTCHANGE notfier in error cases
    cpufreq: pcc: call CPUFREQ_POSTCHANGE notfier in error cases
    ...

    Linus Torvalds
     

21 Jun, 2013

1 commit


04 Jun, 2013

1 commit

  • Ever since commit 45f035ab9b8f ("CONFIG_HOTPLUG should be always on"),
    it has been basically impossible to build a kernel with CONFIG_HOTPLUG
    turned off. Remove all the remaining references to it.

    Cc: Russell King
    Cc: Doug Thompson
    Cc: Bjorn Helgaas
    Cc: Steven Whitehouse
    Cc: Arnd Bergmann
    Cc: Pavel Machek
    Cc: "Rafael J. Wysocki"
    Cc: Andrew Morton
    Signed-off-by: Stephen Rothwell
    Acked-by: Mauro Carvalho Chehab
    Acked-by: Hans Verkuil
    Signed-off-by: Greg Kroah-Hartman

    Stephen Rothwell
     

15 Nov, 2012

1 commit

  • If CONFIG_BOOTPARAM_HOTPLUG_CPU0 is turned on, CPU0 is hotpluggable. Otherwise,
    by default CPU0 is not hotpluggable and kernel parameter cpu0_hotplug enables
    CPU0 online/offline feature.

    The documentations point out two known CPU0 dependencies. First, resume from
    hibernate or suspend always starts from CPU0. So hibernate and suspend are
    prevented if CPU0 is offline. Another dependency is PIC interrupts always go
    to CPU0.

    It's said that some machines may depend on CPU0 to poweroff/reboot. But I
    haven't seen such dependency on a few tested machines.

    Please let me know if you see any CPU0 dependencies on your machine.

    Signed-off-by: Fenghua Yu
    Link: http://lkml.kernel.org/r/1352835171-3958-2-git-send-email-fenghua.yu@intel.com
    Signed-off-by: H. Peter Anvin

    Fenghua Yu
     

29 Mar, 2012

1 commit


31 Mar, 2011

1 commit


11 Aug, 2010

1 commit


17 Dec, 2009

1 commit


24 Nov, 2009

1 commit

  • When a CPU is offlined on POWER currently, we call rtas_stop_self() and hand
    the CPU back to the resource pool. This path is used for DLPAR which will
    cause a change in the LPAR configuration which will be visible outside.

    This patch changes the default state a CPU is put into when it is offlined.
    On platforms which support ceding the processor to the hypervisor with
    latency hint specifier value, during a cpu offline operation,
    instead of calling rtas_stop_self(), we cede the vCPU to the hypervisor
    while passing a latency hint specifier value. The Hypervisor can use this hint
    to provide better energy savings. Also, during the offline
    operation, the control of the vCPU remains with the LPAR as oppposed to
    returning it to the resource pool.

    The patch achieves this by creating an infrastructure to set the
    preferred_offline_state() which can be either
    - CPU_STATE_OFFLINE: which is the current behaviour of calling
    rtas_stop_self()

    - CPU_STATE_INACTIVE: which cedes the vCPU to the hypervisor with the latency
    hint specifier.

    The codepath which wants to perform a DLPAR operation can set the
    preferred_offline_state() of a CPU to CPU_STATE_OFFLINE before invoking
    cpu_down().

    The patch also provides a boot-time command line argument to disable/enable
    CPU_STATE_INACTIVE.

    Signed-off-by: Gautham R Shenoy
    Signed-off-by: Nathan Fontenot
    Signed-off-by: Benjamin Herrenschmidt

    Gautham R Shenoy
     

18 Dec, 2008

1 commit


13 Aug, 2008

1 commit


26 Jan, 2008

2 commits

  • It caused only a lot of confusion. From now on cpu hotplug of up to
    NR_CPUS will work by default. If somebody wants to limit that then
    the possible_cpus parameter can be used.

    Signed-off-by: Heiko Carstens
    Signed-off-by: Martin Schwidefsky

    Heiko Carstens
     
  • Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and use
    get_online_cpus and put_online_cpus instead as it highlights the
    refcount semantics in these operations.

    The new API guarantees protection against the cpu-hotplug operation, but
    it doesn't guarantee serialized access to any of the local data
    structures. Hence the changes needs to be reviewed.

    In case of pseries_add_processor/pseries_remove_processor, use
    cpu_maps_update_begin()/cpu_maps_update_done() as we're modifying the
    cpu_present_map there.

    Signed-off-by: Gautham R Shenoy
    Signed-off-by: Ingo Molnar

    Gautham R Shenoy
     

20 Oct, 2007

1 commit

  • When a cpu is disabled, move_task_off_dead_cpu() is called for tasks that have
    been running on that cpu.

    Currently, such a task is migrated:
    1) to any cpu on the same node as the disabled cpu, which is both online
    and among that task's cpus_allowed
    2) to any cpu which is both online and among that task's cpus_allowed

    It is typical of a multithreaded application running on a large NUMA system to
    have its tasks confined to a cpuset so as to cluster them near the memory that
    they share. Furthermore, it is typical to explicitly place such a task on a
    specific cpu in that cpuset. And in that case the task's cpus_allowed
    includes only a single cpu.

    This patch would insert a preference to migrate such a task to some cpu within
    its cpuset (and set its cpus_allowed to its entire cpuset).

    With this patch, migrate the task to:
    1) to any cpu on the same node as the disabled cpu, which is both online
    and among that task's cpus_allowed
    2) to any online cpu within the task's cpuset
    3) to any cpu which is both online and among that task's cpus_allowed

    In order to do this, move_task_off_dead_cpu() must make a call to
    cpuset_cpus_allowed_locked(), a new subset of cpuset_cpus_allowed(), that will
    not block. (name change - per Oleg's suggestion)

    Calls are made to cpuset_lock() and cpuset_unlock() in migration_call() to set
    the cpuset mutex during the whole migrate_live_tasks() and
    migrate_dead_tasks() procedure.

    [akpm@linux-foundation.org: build fix]
    [pj@sgi.com: Fix indentation and spacing]
    Signed-off-by: Cliff Wickman
    Cc: Oleg Nesterov
    Cc: Christoph Lameter
    Cc: Paul Jackson
    Cc: Ingo Molnar
    Signed-off-by: Paul Jackson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Cliff Wickman
     

10 May, 2007

1 commit

  • Since nonboot CPUs are now disabled after tasks and devices have been
    frozen and the CPU hotplug infrastructure is used for this purpose, we need
    special CPU hotplug notifications that will help the CPU-hotplug-aware
    subsystems distinguish normal CPU hotplug events from CPU hotplug events
    related to a system-wide suspend or resume operation in progress. This
    patch introduces such notifications and causes them to be used during
    suspend and resume transitions. It also changes all of the
    CPU-hotplug-aware subsystems to take these notifications into consideration
    (for now they are handled in the same way as the corresponding "normal"
    ones).

    [oleg@tv-sign.ru: cleanups]
    Signed-off-by: Rafael J. Wysocki
    Cc: Gautham R Shenoy
    Cc: Pavel Machek
    Signed-off-by: Oleg Nesterov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rafael J. Wysocki
     

30 Nov, 2006

1 commit


21 Oct, 2006

1 commit

  • Fixing cpu-hotplug documentation as follows:

    - moving confusing asterisk on additional_cpus descrition
    - fixing some typos
    - unifying indentation for source code and command line example

    Signed-off-by: Satoru Takeuchi
    Cc: Ashok Raj
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Satoru Takeuchi
     

01 Aug, 2006

1 commit


29 Mar, 2006

1 commit


21 Feb, 2006

1 commit

  • Looks like there was a merge conflict when patches
    8f8b1138fc9f65e3591aac83a4ee394fef34ac1d and
    255acee706b333b79f593dd366f16e1f107cccc3 were applied which wasn't properly
    resolved. Fix this and add some additional description.

    Signed-off-by: Heiko Carstens
    Cc: Ashok Raj
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Heiko Carstens
     

18 Feb, 2006

2 commits

  • Introduce possible_cpus command line option. Hard sets the number of bits set
    in cpu_possible_map. Unlike the additional_cpus parameter this one guarantees
    that num_possible_cpus() will stay constant even if the system gets rebooted
    and a different number of cpus are present at startup.

    Signed-off-by: Heiko Carstens
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Heiko Carstens
     
  • Introduce additional_cpus command line option. By default no additional cpu
    can be attached to the system anymore. Only the cpus present at IPL time can
    be switched on/off. If it is desired that additional cpus can be attached to
    the system the maximum number of additional cpus needs to be specified with
    this option.

    This change is necessary in order to limit the waste of per_cpu data
    structures.

    Signed-off-by: Heiko Carstens
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Heiko Carstens
     

17 Feb, 2006

1 commit


09 Jan, 2006

1 commit

  • Thanks to Nathan Lynch for the review and comments. Thanks to Joel Schopp
    for the pointer to add user space scipts.

    Signed-off-by: Ashok Raj
    Signed-off-by: Nathan Lynch
    Signed-off-by: Joel Schopp
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ashok Raj