Re: rfc: high-resolution timer framework

[Alexander Shishkin <alexander.shishkin%teleca.com@localhost>]

On Fri, Aug 01, 2008 at 05:35:04PM +0000, Christos Zoulas wrote:
> In article <20080801145240.GO22423%shisha.spb.ru@localhost>,
> Alexander Shishkin  <alexander.shishkin%teleca.com@localhost> wrote:
> >On Fri, Jul 18, 2008 at 01:50:41PM +0000, Christos Zoulas wrote:
> >Here [1] goes the updated version, please have a look.
> >
> >> >>    be inside the union since they are only used in realtime timers?
> >> >They are only used for CLOCK_HIGHRES timers (which I think at some point
> >> >might take place of realtime timers), but yes, you're right, they belong
> >> >in that union.
> >> 
> >> Actually this was my other question. Why not replace the REALTIME timers
> >> now?
> >Well, I was rather hoping that this code receives a fair amount of
> >testing before it can take the place of CLOCK_REALTIME.
> 
> Well, it will definitely get more testing if it replaces CLOCK_REALTIME :-)
Now I've come to think of it, in the present of these patches it really
is similar to CLOCK_MONOTONIC, not CLOCK_REALTIME, but that's not the
case. I wanted to propose to have both in kernel for a certain time so
that it is easier to compare using various benchmarks, which is better
and what performance issues might arise with both.

After that, if the idea proves feasible (which I hope it does), callout
mechanism could be made to use this approach as well, instead of the
periodic timer interrupt.

And after that, we can start thinking about eliminating the periodic
timer interrupt per se whenever a one-shot hardware timers are
available.

But for now, please once again consider the patchset [1].

[1]: http://koowaldah.org/people/ash/netbsd/070808/

Regards,
--
Alex