Custom Search
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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |
 |