Messages in this thread Patch in this message | | | Subject | Re: Slow pty's (was Re: libdivecomputer interfaces?) | From | Peter Zijlstra <> | Date | Thu, 17 Jun 2010 15:24:04 +0200 |
| |
On Thu, 2010-06-17 at 12:50 +0200, Mike Galbraith wrote:
> sched: do not ratelimit NOHZ when the tick is stopped. > > Chris Wedgwood reports that 39c0cbe sched: Rate-limit nohz causes a serial > console regression, unresponsiveness, and indeed it does. The below fixes > it by not skipping out when the tick has been stopped. > > Tested that the throughput benefit of ratelimiting is still intact. It is. > > Signed-off-by: Mike Galbraith <efault@gmx.de> > Reported-by: Chris Wedgwood <cw@f00f.org>
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c > index 5f171f0..83c5129 100644 > --- a/kernel/time/tick-sched.c > +++ b/kernel/time/tick-sched.c > @@ -315,7 +315,7 @@ void tick_nohz_stop_sched_tick(int inidle) > goto end; > } > > - if (nohz_ratelimit(cpu)) > + if (!ts->tick_stopped && nohz_ratelimit(cpu)) > goto end; > > ts->idle_calls++; >
Humm,. the code around there suggests something like the below, but I must admit its been a while since I really read all that nohz stuff, Thomas, any preferences?
--- kernel/time/tick-sched.c | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 5f171f0..e0707ea 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -315,9 +315,6 @@ void tick_nohz_stop_sched_tick(int inidle) goto end; } - if (nohz_ratelimit(cpu)) - goto end; - ts->idle_calls++; /* Read jiffies and the time when jiffies were updated last */ do { @@ -328,7 +325,7 @@ void tick_nohz_stop_sched_tick(int inidle) } while (read_seqretry(&xtime_lock, seq)); if (rcu_needs_cpu(cpu) || printk_needs_cpu(cpu) || - arch_needs_cpu(cpu)) { + arch_needs_cpu(cpu) || nohz_ratelimit(cpu)) { next_jiffies = last_jiffies + 1; delta_jiffies = 1; } else {
| |