Re: [PATCH 2/3] High-res-timers part 2 (x86 platform code) take 5.1

[Vojtech Pavlik <vojtech@suse.cz>]

On Tue, Oct 15, 2002 at 12:17:47AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > >>This patch, in conjunction with the "core" high-res-timers
> > > >>patch implements high resolution timers on the i386
> > > >>platforms.
> > > > 
> > > > 
> > > > I really don't get the notion of partial ticks, and quite frankly, this 
> > > > isn't going into my tree until some major distribution kicks me in the 
> > > > head and explains to me why the hell we have partial ticks instead of just 
> > > > making the ticks shorter.
> > 
> > Not speaking for a major distro, just for me writing HPET (high
> > performance event timer ...) support for x86-64 (and it happens to exist
> > on ia64 as well, and possibly might be in new Intel P4 chipsets, too).
> > 
> > It's a very nice piece of hardware that allows very fine granularity
> > aperiodic interrupts (in each interrupt you set when the next one will
> > happen), without much overhead.
> 
> I believe the problem is like this: assume you have three timers,
> 10msec polling of mouse, 30msec keyboard autorepeat and 50msec cursor
> blinking. With current approach, you get
> 
> 10msec userland runs
> <enter kernel>
> <process mouse>
> <process keyboard>
> <process cursor>
> <exit kernel>
> 
> With hires timers, you get:
> 
> 3msec userland runs
> <enter kernel>
> <process mouse>
> <exit kernel>
> 2msec userland runs
> <enter kernel>
> <process keyboard>
> <exit kernel>
> ...
> 
> which is not so efficient. I guess rounding could be implemented to
> preserve this "do-all-together" ability?

Actually that's exactly why you'd want sub-tick timing. For timers where
you don't care too much about the timing ;) you could do the rounding,
and for those where you need exact timing (sound, video, ...) you could
call a different add_timer() which would disable the coalescing.

-- 
Vojtech Pavlik
SuSE Labs