Messages in this thread | | | Subject | Re: Is the clockevent resolution fine-grained enough? | Date | 03 Mar 2007 18:46:35 -0800 | From | Marko Rauhamaa <> |
| |
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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |