Dynamic tick for 2.6.14 - what's the plan?

Dynamic tick for 2.6.14 - what's the plan?

[Lee Revell]

The controversy over the introduction of CONFIG_HZ demonstrated the
urgency of getting a dynamic tick solution merged before 2.6.14.

Anyone care to give a status report?  Con, do you feel that the last
version you posted is ready to go in?

Lee

Re: Dynamic tick for 2.6.14 - what's the plan?

[Christopher Friesen]

Lee Revell wrote:
> The controversy over the introduction of CONFIG_HZ demonstrated the
> urgency of getting a dynamic tick solution merged before 2.6.14.
> 
> Anyone care to give a status report?  Con, do you feel that the last
> version you posted is ready to go in?

Last time I got interested in this, the management of the event queues 
was still a fairly major performance hit.

Has this overhead been brought down to reasonable levels?

Chris

Re: Dynamic tick for 2.6.14 - what's the plan?

[Con Kolivas]

On Tue, 30 Aug 2005 08:42, Christopher Friesen wrote:
> Lee Revell wrote:
> > The controversy over the introduction of CONFIG_HZ demonstrated the
> > urgency of getting a dynamic tick solution merged before 2.6.14.
> >
> > Anyone care to give a status report?  Con, do you feel that the last
> > version you posted is ready to go in?
>
> Last time I got interested in this, the management of the event queues
> was still a fairly major performance hit.
>
> Has this overhead been brought down to reasonable levels?

Srivatsa is still working on the smp-aware scalable version, so it's back in 
the development phase.

Cheers,
Con

Re: Dynamic tick for 2.6.14 - what's the plan?

[Theodore Ts'o]

On Tue, Aug 30, 2005 at 10:05:06AM +1000, Con Kolivas wrote:
> On Tue, 30 Aug 2005 08:42, Christopher Friesen wrote:
> > Lee Revell wrote:
> > > The controversy over the introduction of CONFIG_HZ demonstrated the
> > > urgency of getting a dynamic tick solution merged before 2.6.14.
> > >
> > > Anyone care to give a status report?  Con, do you feel that the last
> > > version you posted is ready to go in?
> >
> > Last time I got interested in this, the management of the event queues
> > was still a fairly major performance hit.
> >
> > Has this overhead been brought down to reasonable levels?
> 
> Srivatsa is still working on the smp-aware scalable version, so it's back in 
> the development phase.

Has there been an updated version of Thomas's C-state bus-mastering
measurement patch?

					- Ted

Re: Dynamic tick for 2.6.14 - what's the plan?

[Con Kolivas]

On Tue, 30 Aug 2005 12:54 pm, Theodore Ts'o wrote:
> On Tue, Aug 30, 2005 at 10:05:06AM +1000, Con Kolivas wrote:
> > On Tue, 30 Aug 2005 08:42, Christopher Friesen wrote:
> > > Lee Revell wrote:
> > > > The controversy over the introduction of CONFIG_HZ demonstrated the
> > > > urgency of getting a dynamic tick solution merged before 2.6.14.
> > > >
> > > > Anyone care to give a status report?  Con, do you feel that the last
> > > > version you posted is ready to go in?
> > >
> > > Last time I got interested in this, the management of the event queues
> > > was still a fairly major performance hit.
> > >
> > > Has this overhead been brought down to reasonable levels?
> >
> > Srivatsa is still working on the smp-aware scalable version, so it's back
> > in the development phase.
>
> Has there been an updated version of Thomas's C-state bus-mastering
> measurement patch?

Same issue, it's waiting on dynticks before being reworked.

Cheers,
Con

Re: Dynamic tick for 2.6.14 - what's the plan?

[Tony Lindgren]

* Con Kolivas <kernel@kolivas.org> [050830 06:47]:
> On Tue, 30 Aug 2005 12:54 pm, Theodore Ts'o wrote:
> > On Tue, Aug 30, 2005 at 10:05:06AM +1000, Con Kolivas wrote:
> > > On Tue, 30 Aug 2005 08:42, Christopher Friesen wrote:
> > > > Lee Revell wrote:
> > > > > The controversy over the introduction of CONFIG_HZ demonstrated the
> > > > > urgency of getting a dynamic tick solution merged before 2.6.14.
> > > > >
> > > > > Anyone care to give a status report?  Con, do you feel that the last
> > > > > version you posted is ready to go in?
> > > >
> > > > Last time I got interested in this, the management of the event queues
> > > > was still a fairly major performance hit.
> > > >
> > > > Has this overhead been brought down to reasonable levels?
> > >
> > > Srivatsa is still working on the smp-aware scalable version, so it's back
> > > in the development phase.
> >
> > Has there been an updated version of Thomas's C-state bus-mastering
> > measurement patch?
> 
> Same issue, it's waiting on dynticks before being reworked.

Also one more minor issue; Dyntick can cause slow boots with dyntick
enabled from boot because the there's not much in the timer queue
until init.

This probably does not show up much on x86 though because of the
short hardware timers.

Tony

Re: Dynamic tick for 2.6.14 - what's the plan?

[Alistair John Strachan]

On Tuesday 30 August 2005 13:31, Tony Lindgren wrote:
[snip]
> >
> > Same issue, it's waiting on dynticks before being reworked.
>
> Also one more minor issue; Dyntick can cause slow boots with dyntick
> enabled from boot because the there's not much in the timer queue
> until init.
>
> This probably does not show up much on x86 though because of the
> short hardware timers.

You could disable it until jiffies >= 0; this covers the boot criteria and 
still allows for moderate savings post boot (though maybe on embedded systems 
the delay is too long?).

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: Dynamic tick for 2.6.14 - what's the plan?

[Tony Lindgren]

* Alistair John Strachan <s0348365@sms.ed.ac.uk> [050830 18:57]:
> On Tuesday 30 August 2005 13:31, Tony Lindgren wrote:
> [snip]
> > >
> > > Same issue, it's waiting on dynticks before being reworked.
> >
> > Also one more minor issue; Dyntick can cause slow boots with dyntick
> > enabled from boot because the there's not much in the timer queue
> > until init.
> >
> > This probably does not show up much on x86 though because of the
> > short hardware timers.
> 
> You could disable it until jiffies >= 0; this covers the boot criteria and 
> still allows for moderate savings post boot (though maybe on embedded systems 
> the delay is too long?).

Yeah, that's true. Or just enable it from an init script via sysfs.

Tony

Re: Dynamic tick for 2.6.14 - what's the plan?

[Arjan van de Ven]

On Wed, 2005-08-31 at 10:44 +0300, Tony Lindgren wrote:
> * Alistair John Strachan <s0348365@sms.ed.ac.uk> [050830 18:57]:
> > On Tuesday 30 August 2005 13:31, Tony Lindgren wrote:
> > [snip]
> > > >
> > > > Same issue, it's waiting on dynticks before being reworked.
> > >
> > > Also one more minor issue; Dyntick can cause slow boots with dyntick
> > > enabled from boot because the there's not much in the timer queue
> > > until init.
> > >
> > > This probably does not show up much on x86 though because of the
> > > short hardware timers.
> > 
> > You could disable it until jiffies >= 0; this covers the boot criteria and 
> > still allows for moderate savings post boot (though maybe on embedded systems 
> > the delay is too long?).
> 
> Yeah, that's true. Or just enable it from an init script via sysfs.

ehh
why does it cause slow boots?
if that kind of behavior changes... isn't that a sign there is a
fundamental bug still ?

Re: Dynamic tick for 2.6.14 - what's the plan?

[Tony Lindgren]

* Arjan van de Ven <arjan@infradead.org> [050831 11:40]:
> On Wed, 2005-08-31 at 10:44 +0300, Tony Lindgren wrote:
> > * Alistair John Strachan <s0348365@sms.ed.ac.uk> [050830 18:57]:
> > > On Tuesday 30 August 2005 13:31, Tony Lindgren wrote:
> > > [snip]
> > > > >
> > > > > Same issue, it's waiting on dynticks before being reworked.
> > > >
> > > > Also one more minor issue; Dyntick can cause slow boots with dyntick
> > > > enabled from boot because the there's not much in the timer queue
> > > > until init.
> > > >
> > > > This probably does not show up much on x86 though because of the
> > > > short hardware timers.
> > > 
> > > You could disable it until jiffies >= 0; this covers the boot criteria and 
> > > still allows for moderate savings post boot (though maybe on embedded systems 
> > > the delay is too long?).
> > 
> > Yeah, that's true. Or just enable it from an init script via sysfs.
> 
> ehh
> why does it cause slow boots?
> if that kind of behavior changes... isn't that a sign there is a
> fundamental bug still ?
 
Well it seems like the next_timer_interrupt is something like 400
jiffies away and RCU code waits for completion for example in the
network code.

Tony

Re: Dynamic tick for 2.6.14 - what's the plan?

[Srivatsa Vaddagiri]

On Wed, Aug 31, 2005 at 01:34:03PM +0300, Tony Lindgren wrote:
> Well it seems like the next_timer_interrupt is something like 400
> jiffies away and RCU code waits for completion for example in the
> network code.

I had a patch to fix the problem of "RCU grace period extended 
because of sleeping idle CPUs". I had posted the patch here:

http://marc.theaimsgroup.com/?l=linux-kernel&m=111556608901657&w=2

Will send out this patch against latest tree for Andrew to pick it.

-- 


Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017

Re: Dynamic tick for 2.6.14 - what's the plan?

[Arjan van de Ven]

> > ehh
> > why does it cause slow boots?
> > if that kind of behavior changes... isn't that a sign there is a
> > fundamental bug still ?
>  
> Well it seems like the next_timer_interrupt is something like 400
> jiffies away and RCU code waits for completion for example in the
> network code.

that sounds like a fundamental issue that really needs to be fixed
first!

Re: Dynamic tick for 2.6.14 - what's the plan?

[Srivatsa Vaddagiri]

On Wed, Aug 31, 2005 at 01:03:05PM +0200, Arjan van de Ven wrote:
> that sounds like a fundamental issue that really needs to be fixed
> first!

It should be fixed by the patch here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=111556608901657&w=2

Tony,
	I don't see any slow bootups on x86 because of dyn-tick.
If you still see them in your env, can you test with the patch above?

Recovering time after sleep is the single biggest problem that I seem
to have, even while using ACPI PM timer (forget TSC). Time can
drift by couple of seconds after few hours. I have made
some changes to the lost tick calculation in timer_pm.c after which
it seems to be stable on some machines, but I cant repeat that
on other (maybe newer) machines. Will post out all the changes I have
pretty soon.

-- 


Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017

Re: Dynamic tick for 2.6.14 - what's the plan?

[Srivatsa Vaddagiri]

On Wed, Aug 31, 2005 at 04:47:05PM +0530, Srivatsa Vaddagiri wrote:
> On Wed, Aug 31, 2005 at 01:03:05PM +0200, Arjan van de Ven wrote:
> > that sounds like a fundamental issue that really needs to be fixed
> > first!
> 
> It should be fixed by the patch here:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=111556608901657&w=2

Actually, a solution to take care of sleeping CPUs was there quite some 
time back. The above patch only fixes a race in that solution.

Tony,
	Which kernel version did you see the slow bootup? 

-- 


Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017

Re: Dynamic tick for 2.6.14 - what's the plan?

[Tony Lindgren]

* Srivatsa Vaddagiri <vatsa@in.ibm.com> [050831 14:20]:
> On Wed, Aug 31, 2005 at 04:47:05PM +0530, Srivatsa Vaddagiri wrote:
> > On Wed, Aug 31, 2005 at 01:03:05PM +0200, Arjan van de Ven wrote:
> > > that sounds like a fundamental issue that really needs to be fixed
> > > first!
> > 
> > It should be fixed by the patch here:
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=111556608901657&w=2
> 
> Actually, a solution to take care of sleeping CPUs was there quite some 
> time back. The above patch only fixes a race in that solution.
> 
> Tony,
> 	Which kernel version did you see the slow bootup? 

I'll try it out, but sounds like it won't help then.

This is on ARM OMAP and 2.6.12. I haven't been able to play with the
x86 stuff lately, hopefully will have a chance soonish...

Tony

Re: Dynamic tick for 2.6.14 - what's the plan?

[Srivatsa Vaddagiri]

On Mon, Aug 29, 2005 at 10:43:45PM +0000, Christopher Friesen wrote:
> Last time I got interested in this, the management of the event queues 
> was still a fairly major performance hit.
> 
> Has this overhead been brought down to reasonable levels?

Hmm ..I dont see any event queues being managed by dyn-tick patch. 
Are you referring to some old version which I havent seen perhaps?
If so, what were those event queues used for?


-- 


Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017

Re: Dynamic tick for 2.6.14 - what's the plan?

[Christopher Friesen]

Srivatsa Vaddagiri wrote:
> On Mon, Aug 29, 2005 at 10:43:45PM +0000, Christopher Friesen wrote:
>>Last time I got interested in this, the management of the event queues 
>>was still a fairly major performance hit.

> Hmm ..I dont see any event queues being managed by dyn-tick patch. 
> Are you referring to some old version which I havent seen perhaps?
> If so, what were those event queues used for?

Oh, sorry.  I think I got this confused with the tickless patch.

Chris

Re: Dynamic tick for 2.6.14 - what's the plan?

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [050831 16:21]:
> * Srivatsa Vaddagiri <vatsa@in.ibm.com> [050831 14:20]:
> > On Wed, Aug 31, 2005 at 04:47:05PM +0530, Srivatsa Vaddagiri wrote:
> > > On Wed, Aug 31, 2005 at 01:03:05PM +0200, Arjan van de Ven wrote:
> > > > that sounds like a fundamental issue that really needs to be fixed
> > > > first!
> > > 
> > > It should be fixed by the patch here:
> > > http://marc.theaimsgroup.com/?l=linux-kernel&m=111556608901657&w=2
> > 
> > Actually, a solution to take care of sleeping CPUs was there quite some 
> > time back. The above patch only fixes a race in that solution.
> > 
> > Tony,
> > 	Which kernel version did you see the slow bootup? 
> 
> I'll try it out, but sounds like it won't help then.
> 
> This is on ARM OMAP and 2.6.12. I haven't been able to play with the
> x86 stuff lately, hopefully will have a chance soonish...

It could be that the slow bootup is currently just OMAP specific issue,
I'll post more info when I find out.

Tony