Re: dynamic-hz

From: Tony Lindgren <tony@atomide.com>
To: Pavel Machek <pavel@suse.cz>
Cc: john stultz <johnstul@us.ibm.com>,
	Andrea Arcangeli <andrea@suse.de>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>,
	Con Kolivas <kernel@kolivas.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: dynamic-hz
Date: Tue, 14 Dec 2004 13:18:14 -0800	[thread overview]
Message-ID: <20041214211814.GA31226@atomide.com> (raw)
In-Reply-To: <20041214093735.GA1063@elf.ucw.cz>

* Pavel Machek <pavel@suse.cz> [041214 01:38]:
> Hi!
> 
> > > > > > > But that does not matter, right? Yes, one-shot timer will not fire
> > > > > > > exactly at right place, but as long as you are reading TSC and basing
> > > > > > > next shot on current time, error should not accumulate.
> > > > > > 
> > > > > > As said in the rest of the message, the error (or some other error)
> > > > > > accumulates heavily today in the tick-loss compensation/adjustment
> > > > > > algorithm in arch/i386/kernel/timers/timer_tsc.c, so I'm sceptical
> > > > > > about
> > > > > 
> > > > > I do not see how it should accumulate. Lets have working TSC. You want
> > > > > to emulate fixed-period timer with single-shot timer.
> > > > 
> > > > Its caused by the fact that we don't use the the TSC to accumulate time.
> > > > We are instead interpolating between timer ticks and the TSC, where
> > > 
> > > Yes, it was supposed to be simple, so that Andrea understands that
> > > there's nothing inherently broken with single-shot timers.
> > 
> > Just a quick comment; The timer does not need to be single-shot 
> > all the time, it can be a combination of continuous and variable
> > length timer, and it can change depending on the system load.
> > 
> > We recently added VST support for OMAP in linux-omap bk tree, and 
> > made some changes to the previous VST implementations that might be
> > of interest:
> ...
> > The patch in question is at:
> > 
> > http://linux-omap.bkbits.net:8080/main/user=tmlind/patch@1.2016.4.18?nav=!-|index.html|stats|!+|index.html|ChangeSet@-12w|cset@1.2016.4.18
> 
> Wow, that's basically 8 lines of code plus driver for new
> hardware... Is it really that simple?

Yeah, the key things are reprogramming the timer in the idle loop
based on next_timer_interrupt(), and calling timer_interrupt from
other interrupts as well :)

Should we try a similar patch for x86/amd64? I'm not sure which timers
to use though? One should be programmable length for the interrupt, 
and the other continuous for the timekeeping.

BTW, looks like my upgraded mail server is still a bit messed up, and
my original post did not make it to the list. But most of the message
is quoted above anyways. Here's the link to the patch again as
tinyurl:

http://tinyurl.com/69n4k

Tony