lkml.org 
[lkml]   [2004]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:5.668 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site