[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.02.1205310932240.3231@ionos>
Date: Thu, 31 May 2012 09:36:56 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Alan Stern <stern@...land.harvard.edu>
cc: Ingo Molnar <mingo@...hat.com>,
Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Use of high-res timers
On Wed, 30 May 2012, Alan Stern wrote:
> Thomas, Ingo, or anyone else:
>
> My driver needs to time a bunch of events, with roughly millisecond
> precision. Up to now it has used old-fashioned timer_lists and the
> jiffies counter, but I'm switching over to high-resolution timers and
> ktime_get.
>
> This leads to a few questions (these issues don't seem to be addressed
> anywhere in Documentation/timers):
>
> Should I be concerned about efficiency? I may well end up
> calling ktime_get several times per millisecond; is it fast
> enough for this to be okay?
It better is.
> I need timed intervals with reliable lower bounds. Let's say
> I call ktime_get twice, maybe once in an interrupt handler and
> once in an hrtimer callback (not necessarily on the same CPU).
> Some action has to be taken no earlier than 1 ms after the
> first call. If the second call returns a value that is at
> least 1 ms larger than the first call, is that enough of a
> guarantee? If not, how much larger does it have to be?
ktime_get() is precise. Can you explain what you are trying to solve ?
> Which has more overhead: adding and cancelling an hrtimer
> several times, or simply letting it expire and returning
> immediately from the callback? (I wouldn't be surprised if
> there was no good answer.)
There is no really good answer.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists