lkml.org 
[lkml]   [2011]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 09/32] nohz: Move ts->idle_calls into strict idle logic
On Mon, Aug 29, 2011 at 08:33:23PM +0200, Peter Zijlstra wrote:
> On Mon, 2011-08-29 at 20:23 +0200, Frederic Weisbecker wrote:
>
> > > Well, no, on interrupt return you shouldn't do anything. If you've
> > > stopped the tick it stays stopped until you do something that needs it,
> > > then that action will re-enable it.
> >
> > Sure, when something needs the tick in this mode, we usually
> > receive an IPI and restart the tick from there but then
> > tick_nohz_stop_sched_tick() handles the cases with *needs_cpu()
> > very well on interrupt return (our IPI return) by doing a kind
> > of "light" HZ mode by logically switching to nohz mode but
> > with the next timer happening in HZ, assuming it's a matter
> > of one tick and we will switch to a real nohz behaviour soon.
> >
> > I don't see a good reason to duplicate that logic with a pure
> > restart from the IPI.
>
> That sounds like an optimization, and should thus be done later.

The optimization is already there upstream. I can split the logic for
non-idle case but I'm not sure about the point of that.

> > > > That said I wonder if some of the above conditions should restore a periodic
> > > > behaviour on interrupt return...
> > >
> > > I would expect the tick not to be stopped when tick_nohz_can_stop_tick()
> > > returns false. If it returns true, then I expect anything that needs it
> > > to re-enable it.
> > >
> >
> > Yeah. In the case of need_resched() in idle I believe the CPU doesn't
> > really go to sleep later so it should be fine. But for the case of
> > softirq pending or nohz_mode, I'm not sure...
>
> softirqs shouldn't be pending when you go into nohz mode..

You mean it can't happen or we don't want that to happen?

>
> That is, I'm really not seeing what's wrong with the very simple:
>
>
> if (tick_nohz_can_stop_tick())
> tick_nohz_stop_tick();
>
>
> and relying on everybody who invalidates tick_nohz_can_stop_tick(), to
> do:
>
> tick_nohz_start_tick();

May be for the non-idle case. But for the idle case I need to ensure
this is necessary somewhere.

>
> I'm also not quite sure why you always IPI, is that to avoid lock
> inversions?

Exactly! I think I wrote that to some changelog but I'm not sure. I'll
check that.


\
 
 \ /
  Last update: 2011-08-30 16:47    [W:0.176 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site