* Ingo Molnar ([EMAIL PROTECTED]) wrote: > > * Daniel Walker <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
