Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]

["K.R. Foley" <kr@cybsft.com>]

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/
>