Ingo,
Please pull the latest full dynticks branch that can found at:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
timers/nohz
HEAD: 67826eae8c16dbf00c262be6ec15021bb42f69c4
This handles perf and CPUs that get more than one task and fix posix cpu timers
handling.
This can finally stop the tick. It boots and doesn't crash, as far as I tested.
Now what's left:
* Kick CPUs' tick when the clock is marked unstable
* Kick CPUs when they extend the RCU grace periods too much by staying in
the kernel for too long (we are discussing this with Paul).
* sched_class:task_tick(). There are gazillions statistics maintained there.
It's probably mostly about local and global fairness. May be for other stuff
too (cgroups, etc...).
* update_cpu_load_active(): again, various stats maintained there
* load balancing (see trigger_load_balance() usually called from the tick).
I hope we can handle these things progressively in the long run.
Thanks.
---
Frederic Weisbecker (10):
posix_timers: Fix pre-condition to stop the tick on full dynticks
perf: Kick full dynticks CPU if events rotation is needed
perf: New helper to prevent full dynticks CPUs from stopping tick
sched: Kick full dynticks CPU that have more than one task enqueued.
sched: New helper to prevent from stopping the tick in full dynticks
nohz: Re-evaluate the tick from the scheduler IPI
nohz: Implement full dynticks kick
nohz: Prepare to stop the tick on irq exit
nohz: Re-evaluate the tick for the new task after a context switch
nohz: Disable the tick when irq resume in full dynticks CPU
include/linux/perf_event.h | 6 +++
include/linux/sched.h | 6 +++
include/linux/tick.h | 4 ++
kernel/events/core.c | 17 +++++++-
kernel/posix-cpu-timers.c | 6 +-
kernel/sched/core.c | 24 +++++++++++-
kernel/sched/sched.h | 11 +++++
kernel/softirq.c | 19 ++++++--
kernel/time/tick-sched.c | 95 ++++++++++++++++++++++++++++++++++++++-----
9 files changed, 167 insertions(+), 21 deletions(-)
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
