Re: [PATCH] clean up FIXME in do_timer_interrupt
From: George Anzinger
Date: Fri Mar 04 2005 - 17:27:18 EST
Lee Revell wrote:
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 thing 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.
Well, it does have to be done at the right WRT the second, but I suspect we can
hit that as well with a timer as it is hit now. Also, if we are _really_ off
the mark, this can be defered till the next second.
--
George Anzinger george@xxxxxxxxxx
High-res-timers: http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/