Skip to content
Snippets Groups Projects
Select Git revision
  • llvm_v4.8
  • dev_smp_nullb
  • dev_smp
  • dev_nullb
  • lcd_v4.8 default
  • dev_foobar
  • dev_ixgbe
  • dev_netdummy
  • depriv
  • dev_idl_4.8_no_channels
  • dev_idl_4.8
  • dev_idl
  • temp_lcd_v4.8
  • idl_fixes
  • lcd
  • lcd_stack_protector
  • irq
  • pmfs
  • dev_nvme
  • async
  • sosp-19
  • v3.11.3
  • v3.10.14
  • v3.4.64
  • v3.0.98
  • v3.12-rc3
  • v3.11.2
  • v3.10.13
  • v3.4.63
  • v3.0.97
  • v3.12-rc2
  • v3.12-rc1
  • v3.11.1
  • v3.10.12
  • v3.4.62
  • v3.0.96
  • v3.2.51
  • v3.10.11
  • v3.4.61
  • v3.0.95
40 results
Search by author
  • Any Author
  • Abhiram Balasubramanian Abhiram Balasubramanian abhiram
  • Anton Burtsev Anton Burtsev aburtsev
  • Charlie Jacobsen Charlie Jacobsen cjacobsen
  • David Detweiler David Detweiler ddetweiler
  • David Johnson David Johnson johnsond
  • Michael Quigley Michael Quigley MichaelQuigley
  • Mike Hibler Mike Hibler hibler
  • Robert Ricci Robert Ricci ricci
  • Sarah Spall Sarah Spall spall
  • Scotty Bauer Scotty Bauer ScottyB
  • Vikram Narayanan Vikram Narayanan vikram
11 authors
  1. May 02, 2011
  3. Apr 29, 2011
    • Tejun Heo's avatar
      workqueue: fix deadlock in worker_maybe_bind_and_lock() · 5035b20f
      Tejun Heo authored 
      If a rescuer and stop_machine() bringing down a CPU race with each
other, they may deadlock on non-preemptive kernel.  The CPU won't
accept a new task, so the rescuer can't migrate to the target CPU,
while stop_machine() can't proceed because the rescuer is holding one
of the CPU retrying migration.  GCWQ_DISASSOCIATED is never cleared
and worker_maybe_bind_and_lock() retries indefinitely.

This problem can be reproduced semi reliably while the system is
entering suspend.

 http://thread.gmane.org/gmane.linux.kernel/1122051



A lot of kudos to Thilo-Alexander for reporting this tricky issue and
painstaking testing.

stable: This affects all kernels with cmwq, so all kernels since and
        including v2.6.36 need this fix.

Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Reported-by: default avatarThilo-Alexander Ginkel <thilo@ginkel.com>
Tested-by: default avatarThilo-Alexander Ginkel <thilo@ginkel.com>
Cc: stable@kernel.org
      5035b20f
    • Thomas Gleixner's avatar
      hrtimer: Initialize CLOCK_ID to HRTIMER_BASE table statically · ce31332d
      Thomas Gleixner authored 
      
Sedat and Bruno reported RCU stalls which turned out to be caused by
the following;

sched_init() calls init_rt_bandwidth() which calls hrtimer_init()
_BEFORE_ hrtimers_init() is called. While not entirely correct this
worked because hrtimer_init() only accessed statically initialized
data (hrtimer_bases.clock_base[CLOCK_MONOTONIC])

Commit e06383db (hrtimers: extend hrtimer base code to handle more
then 2 clockids) added an indirection to the hrtimer_bases.clock_base
lookup to avoid gap handling in the hot path. The table which is used
for the translataion from CLOCK_ID to HRTIMER_BASE index is
initialized at runtime in hrtimers_init(). So the early call of the
scheduler code translates CLOCK_MONOTONIC to HRTIMER_BASE_REALTIME.

Thus the rt_bandwith timer ends up on CLOCK_REALTIME. If the timer is
armed and the wall clock time is set (e.g. ntpdate in the early boot
process - which also gives the problem deterministic behaviour
i.e. magic recovery after N hours), then the timer ends up with an
expiry time far into the future. That breaks the RT throttler
mechanism as rt runtime is accumulated and never cleared, so the rt
throttler detects a false cpu hog condition and blocks all RT tasks
until the timer finally expires. That in turn stalls the RCU thread of
TINYRCU which leads to an huge amount of RCU callbacks piling up.

Make the translation table statically initialized, so we are back to
the status of <= 2.6.39.

Reported-and-tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
Reported-by: default avatarBruno Prémont <bonbons@linux-vserver.org>
Cc: John stultz <johnstul@us.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/%3Calpine.LFD.2.02.1104282353140.3005%40ionos%3E


Reviewed-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      ce31332d
  5. Apr 28, 2011
  7. Apr 21, 2011
  9. Apr 19, 2011
  11. Apr 18, 2011
  13. Apr 16, 2011
    • Jens Axboe's avatar
      block: make unplug timer trace event correspond to the schedule() unplug · 49cac01e
      Jens Axboe authored 
      
It's a pretty close match to what we had before - the timer triggering
would mean that nobody unplugged the plug in due time, in the new
scheme this matches very closely what the schedule() unplug now is.
It's essentially the difference between an explicit unplug (IO unplug)
or an implicit unplug (timer unplug, we scheduled with pending IO
queued).

Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      49cac01e
    • Jens Axboe's avatar
      block: let io_schedule() flush the plug inline · a237c1c5
      Jens Axboe authored 
      
Linus correctly observes that the most important dispatch cases
are now done from kblockd, this isn't ideal for latency reasons.
The original reason for switching dispatches out-of-line was to
avoid too deep a stack, so by _only_ letting the "accidental"
flush directly in schedule() be guarded by offload to kblockd,
we should be able to get the best of both worlds.

So add a blk_schedule_flush_plug() that offloads to kblockd,
and only use that from the schedule() path.

Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      a237c1c5
  15. Apr 15, 2011
  17. Apr 13, 2011
  19. Apr 12, 2011
  21. Apr 11, 2011
    • Shriram Rajagopalan's avatar
      fix XEN_SAVE_RESTORE Kconfig dependencies · d419e4c0
      Shriram Rajagopalan authored 
      
Make XEN_SAVE_RESTORE select HIBERNATE_CALLBACKS.
Remove XEN_SAVE_RESTORE dependency from PM_SLEEP.

Signed-off-by: default avatarShriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: default avatarIan Campbell <ian.campbell@citrix.com>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      d419e4c0
    • Rafael J. Wysocki's avatar
      PM / Hibernate: Introduce CONFIG_HIBERNATE_CALLBACKS · 1f112cee
      Rafael J. Wysocki authored 
      
Xen save/restore is going to use hibernate device callbacks for
quiescing devices and putting them back to normal operations and it
would need to select CONFIG_HIBERNATION for this purpose.  However,
that also would cause the hibernate interfaces for user space to be
enabled, which might confuse user space, because the Xen kernels
don't support hibernation.  Moreover, it would be wasteful, as it
would make the Xen kernels include a substantial amount of code that
they would never use.

To address this issue introduce new power management Kconfig option
CONFIG_HIBERNATE_CALLBACKS, such that it will only select the code
that is necessary for the hibernate device callbacks to work and make
CONFIG_HIBERNATION select it.  Then, Xen save/restore will be able to
select CONFIG_HIBERNATE_CALLBACKS without dragging the entire
hibernate code along with it.

Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Tested-by: default avatarShriram Rajagopalan <rshriram@cs.ubc.ca>
      1f112cee
    • Ken Chen's avatar
      sched: Fix erroneous all_pinned logic · b30aef17
      Ken Chen authored 
      
The scheduler load balancer has specific code to deal with cases of
unbalanced system due to lots of unmovable tasks (for example because of
hard CPU affinity). In those situation, it excludes the busiest CPU that
has pinned tasks for load balance consideration such that it can perform
second 2nd load balance pass on the rest of the system.

This all works as designed if there is only one cgroup in the system.

However, when we have multiple cgroups, this logic has false positives and
triggers multiple load balance passes despite there are actually no pinned
tasks at all.

The reason it has false positives is that the all pinned logic is deep in
the lowest function of can_migrate_task() and is too low level:

load_balance_fair() iterates each task group and calls balance_tasks() to
migrate target load. Along the way, balance_tasks() will also set a
all_pinned variable. Given that task-groups are iterated, this all_pinned
variable is essentially the status of last group in the scanning process.
Task group can have number of reasons that no load being migrated, none
due to cpu affinity. However, this status bit is being propagated back up
to the higher level load_balance(), which incorrectly think that no tasks
were moved.  It kick off the all pinned logic and start multiple passes
attempt to move load onto puller CPU.

To fix this, move the all_pinned aggregation up at the iterator level.
This ensures that the status is aggregated over all task-groups, not just
last one in the list.

Signed-off-by: default avatarKen Chen <kenchen@google.com>
Cc: stable@kernel.org
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/BANLkTi=ernzNawaR5tJZEsV_QVnfxqXmsQ@mail.gmail.com


Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b30aef17
    • Ken Chen's avatar
      sched: Fix sched-domain avg_load calculation · b0432d8f
      Ken Chen authored 
      
In function find_busiest_group(), the sched-domain avg_load isn't
calculated at all if there is a group imbalance within the domain. This
will cause erroneous imbalance calculation.

The reason is that calculate_imbalance() sees sds->avg_load = 0 and it
will dump entire sds->max_load into imbalance variable, which is used
later on to migrate entire load from busiest CPU to the puller CPU.

This has two really bad effect:

1. stampede of task migration, and they won't be able to break out
   of the bad state because of positive feedback loop: large load
   delta -> heavier load migration -> larger imbalance and the cycle
   goes on.

2. severe imbalance in CPU queue depth.  This causes really long
   scheduling latency blip which affects badly on application that
   has tight latency requirement.

The fix is to have kernel calculate domain avg_load in both cases. This
will ensure that imbalance calculation is always sensible and the target
is usually half way between busiest and puller CPU.

Signed-off-by: default avatarKen Chen <kenchen@google.com>
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/20110408002322.3A0D812217F@elm.corp.google.com


Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b0432d8f
    • Stephane Eranian's avatar
      perf_event: Fix cgrp event scheduling bug in perf_enable_on_exec() · e566b76e
      Stephane Eranian authored 
      
There is a bug in perf_event_enable_on_exec() when cgroup events are
active on a CPU: the cgroup events may be scheduled twice causing event
state corruptions which eventually may lead to kernel panics.

The reason is that the function needs to first schedule out the cgroup
events, just like for the per-thread events. The cgroup event are
scheduled back in automatically from the perf_event_context_sched_in()
function.

The patch also adds a WARN_ON_ONCE() is perf_cgroup_switch() to catch any
bogus state.

Signed-off-by: default avatarStephane Eranian <eranian@google.com>
Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20110406005454.GA1062@quad


Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e566b76e
  23. Apr 08, 2011
  25. Apr 05, 2011
  27. Apr 04, 2011
  29. Apr 02, 2011
  31. Mar 31, 2011
  33. Mar 30, 2011
  35. Mar 29, 2011
  37. Mar 28, 2011