lkml.org 
[lkml]   [2007]   [Feb]   [27]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateTue, 27 Feb 2007 02:38:15 -0500
FromMathieu Desnoyers <>
SubjectRe: [RFC] Fast assurate clock readable from user space and NMI handler
* Ingo Molnar (mingo@elte.hu) wrote:
> 
> * Daniel Walker <dwalker@mvista.com> wrote:
> 
> > The pit clocksource could be dropped pretty easy with my clocksource 
> > update patches, which I'm still working on but you could easily drop 
> > clock sources that aren't atomic like the pit .. Also the pit is 
> > generally undesirable, so it's not going to be missed.
> 
> that's totally unacceptable, and i'm amazed you are even suggesting it - 
> often the PIT ends up being the most reliable hardware clock in a PC. 
> Btw., what's wrong with the spinlock that is protecting PIT access? It 
> expresses the non-atomic property of the PIT just fine.
> 

I am concerned about the automatic fallback to the PIT when no other
clock source is available. A clocksource read would be atomic when TSC
or HPET are available, but would fall back on PIT otherwise. There
should be some way to specify that a caller is only interested in atomic
clock sources (if none are available, the call should simply return an
error, or 0).

I still think that an RCU style update mechanism would be a good way  to
fix the current clocksource read issue. Another, slower and non NMI
safe way to do this would be with a read seqlock and with IRQ disabling.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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/

\
 
 \ /
  Last update: 2007-02-27 08:41    [from the cache]
©2003-2008