Re: Is the clockevent resolution fine-grained enough?

[Marko Rauhamaa <marko@pacujo.net>]

Thomas Gleixner <tglx@linutronix.de>:

> 100khz on a stock kernel with real world hardware:
> 
> ROTFL, You made my day. 

I don't know why you find that rate unbelievable.

> Sorry man. Did you actually read what I wrote ? 
> 
> > The clockevent subsystem operates on absolute time, so there is no
> > cummulative error

You are right. I misunderstood what you meant by "absolute time".

> timer_function()
> {
> 	do_whatever_you_need_to_do();
> 
> 	next_event += interval;
> 	set_next_event(yokto_seconds_to_nsec(next_event), ABSOLUTE);
> }
> 
> Please read _AND_ understand the clockevents code. Your uber_clockevents
> patch is solving PEBKAC.

I tried to quickly reconstruct the API from a recent clockevent patch I
found with google (<URL:
http://www.mail-archive.com/mm-commits@vger.kernel.org/msg09566.html>).
I saw the enum "CLOCK_EVT_MODE_PERIODIC" and automatically thought of
using that since my application is periodic. I imagined you wouldn't
have to keep on ordering the notification again in every callback. It's
also difficult to estimate how expensive an operation the explicit
rearming would be in the clock event device (the periodic notifications
can probably be optimized effectively).

You are right. By calling set_next_event() in every callback I can
implement what I want (provided that the API guarantees that the
absolute time can be in the past).


Marko

-- 
Marko Rauhamaa      mailto:marko@pacujo.net     http://pacujo.net/marko/