Messages in this thread | | | Date | Mon, 1 Nov 2004 14:42:35 +0100 | From | Ingo Molnar <> | Subject | Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4] |
| |
* Florian Schmidt <mista.tapas@gmx.net> wrote:
> new max. jitter: 4.3% (41 usec) > new max. jitter: 4.9% (47 usec)
a couple of conceptual questions: why does rtc_wakeup poll() on /dev/rtc? Shouldnt a read() be enough?
i'm seeing some weird traces, which show rtc_wakeup doing this cycle:
[~900 usecs pass]
hardirq 8 comes in, wakes IRQ 8 thread IRQ 8 thread wakes up rtc_wakeup
rtc_wakeup fast-thread returns from sys_read() rtc_wakeup fast-thread enters sys_poll() and returns immediately rtc_wakeup fast-thread enters sys_read() and blocks
rtc_wakeup slow-thread runs and does the calculations.
[repeat]
this i think shows that the logic is wrong somewhere and that read() will achieve the blocking. This also means that the sys_read()-return + sys_poll() overhead is added to the 'IRQ wakeup' overhead!
removing the poll() lines doesnt seem to impact the quality of the data, but i still see roughly 50 usecs added to the 'real' latency that i see in traces.
Ingo - 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/
| |