diff options
| author | Vikram Mulukutla <markivx@codeaurora.org> | 2016-11-08 15:21:41 -0800 |
|---|---|---|
| committer | Vikram Mulukutla <markivx@codeaurora.org> | 2016-11-09 15:57:24 -0800 |
| commit | 4142e30898e344a7b86782821ca200ca7d97ff76 (patch) | |
| tree | a1f03bf36b8df714c633a437e92c46fa68662a3a /lib/mpi/mpi-bit.c | |
| parent | 85d7e134cc5d95dfd3a1a5ee5a1d1435633288cd (diff) | |
timer: Don't wait for running timers when migrating during isolation
A CPU that is isolated needs to have its timers migrated off to
another CPU. If while migrating timers, there is a running
timer, acquiring the timer base lock after marking a CPU as
isolated will ensure that:
1) No more timers can be queued on to the isolated CPU, and
2) A running timer will finish execution on the to-be-isolated
CPU, and so will any just expired timers since they're all
taken off of the CPU's tvec1 in one go while the base lock
is held.
Therefore there is no apparent reason to wait for the expired
timers to finish execution, and isolation can proceed to migrate
non-expired timers even when the expired ones are running
concurrently.
While we're here, also add a delay to the wait-loop inside
migrate_hrtimer_list to allow for store-exclusive fairness
when run_hrtimer is attempting to grab the hrtimer base
lock.
Change-Id: Ib697476c93c60e3d213aaa8fff0a2bcc2985bfce
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
Diffstat (limited to 'lib/mpi/mpi-bit.c')
0 files changed, 0 insertions, 0 deletions
