Re: rt file i/o

[Sven-Thorsten Dietrich <sven@thebigcorporation.com>]

On 11/04/2009 09:14 AM, Nicholas Mc Guire wrote:
> On Wed, 04 Nov 2009, Tim Blechmann wrote:
>
>    
>>>     I'm not a developer and cannot really address your specific
>>> question but for my use of the rt-kernel I put important rt-audio
>>> files on a 1394 drive and give the 1394 driver higher priorities using
>>> the IRQ scheduling tools. I don't have any trouble running 2 or 3 1394
>>> drives recording and playing back 48 channels in Ardour.
>>>
>>>     While I agree you should do everything the right way technically in
>>> the code maybe part of your solution is outside of the app you are
>>> writing and in the use of these support tools?
>>>        
>> well, if i understand the rt howto correctly, _no_ disc access is
>> allowed, neither from rt nor from non-rt threads, since it may produce
>> page faults, which introduce latencies ...
>>      
> I would be supprised if the rt howto states that page-faults in non-rt
> threads is a critical problem - that would not significantly impact RT
> performance - atelast not the worst case - it will (as every other system
> load) impact the average case. so having a non-rt thread reading disk-files
> to a buffer and a rt-thread processing this buffer should be perfectly fine.
>
>    

Ack. I agree with Herr Hofrat, and would only add, that it is helpful to 
pre-allocate and mlock() memory you use to pipe data from RT tasks to 
the I/O subsystem.

It is possible to trigger delays in a priority-agnostic manner when a 
large number of tasks end up all hammering heavily on malloc().

Sven

> hofrat
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>