On Fri, 2005-03-04 at 02:28 -0800, George Anzinger wrote: > Lee Revell wrote: > > On Thu, 2005-03-03 at 16:45 -0800, Andrew Morton wrote: > > > >>If efi_enabled is true and efi_set_rtc_mmss(xtime.tv_sec) returns zero, the > >>new code will run set_rtc_mmss(xtime.tv_sec) whereas the old code won't. > > > > > > Argh, I should know better then to send patches before having coffee. > > > > Here's a new patch. Still ugly, but might be a worthwhile cleanup. > > Lets ask the obvious question: Why isn't this update hung on a timer? It > seems > silly to check this 6000 times per update. I am sure we can sync a timer to > the > same degree we do timer interrupts, so there _must_ be some other reason. > Right? >
Thanks George, I knew there was an obvious question here, I just didn't know what it was ;-). The thin that brought this code to my attention is that with PREEMPT_RT this happens to be the longest non-preemptible code path in the kernel. On my 1.3 Ghz machine set_rtc_mmss takes about 50 usecs, combined with the rest of timer irq we end up disabling preemption for about 90 usecs. Unfortunately I don't have the trace anymore. Anyway the upshot is if we hung this off a timer it looks like we would improve the worst case latency with PREEMPT_RT by almost 50%. Unless there is some reason it has to be done synchronously of course. Lee - 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/
