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