Messages in this thread | | | Date | Mon, 01 Nov 2004 09:29:38 -0600 | From | "K.R. Foley" <> | Subject | Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4] |
| |
Florian Schmidt wrote: > On Mon, 1 Nov 2004 14:42:35 +0100 > Ingo Molnar <mingo@elte.hu> wrote: > > >>* 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? > > > well, it works like this: > > > while(!stopit) { > // returns when data is ready > poll(on /dev/rtc); > > // when ready generate the timestamp > cycles = get_cycles(); > > // now read the data > read(on /dev/rtc); > > // and now stuff the data (including timestamp) into the ringbuffer > > // rinse and repeat > } > > i get the timestamp before reading because i figured i want to take the > timestamp as close as possible to data being available. The read() and > passing the data to the other thread done after the timestamp generation (in > that ca. 1 - 0.1 ms (1024 - 8192 hz) time window which we have until the > next irq occurs) > > >>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 > > > weird. why could poll return immeaditly? Only when data should be available > right? Ahh, maybe there's less data available than which is needed by > read(). I suppose i need to check if enough data is available. If not, > repoll(), then generate the timestamp. Then read(). I had the impression > that this small amount of data which rtc delivers (4 bytes i think) would > not be split into smaller parts. > > It never occured to me that poll() could return with incomplete rtc data > available.. > > As i don't know of any way of finding out how much data is available i > suppose we can just make the poll() a read(). I suppose overhead is > neglectable right? > Someone please correct me if I'm wrong, but is there any MORE overhead associated with a blocking read than with a poll or select? Won't the process just go to sleep until there is data available?
> >> 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. > > > - > 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/ >
- 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/
| |