On Wed, 04 Nov 2009, Tim Blechmann wrote: > hi all, > > having read the howto build an rt-application, i am trying to think of a > way to handle disk i/o in my application. > > the howto suggest to avoid file i/o in non-rt helper threads, but to > move them to another process. while the howto suggests using network > socket, i'm curious, if other ipc primitives like shared memory would > give better throughput? or would i experience any issues, like is it > possible to lock shared memory to physical ram? > this is probably a bit off topic - but both RTLinux/GPL (RTLFS) and L4 have implemented RT IDE drivers - limited to dedicated discs - the performance is really bad (aprox. 800k/s) - so determinism on a device that really lives from cache/pre-fetch and large-block access is very expensive. What such a driver can give you at best is a guaranteed bandwidth, and a worst case latency that is not really too atractive (tens of milliseconds) So probably the best option is to have a user-space/non-RT driver access the disk and pre-fetch/cache a "large" chunk of what you want to read/write to de-couple RT from non-RT - this has been the model used i.e. for RAT (Real-time Audio Tools see proceedings of the 6th Real Time Linux Workshop - Singapur) quite successfully - as long as the I/O rate your RT-app expects is sufficiently much smaller than the I/O capability of the device driver AND you ensure the bandwidth (i.e. by raising the respective irq-thread priority, and restricting other I/O to that controler/disk) this is actually a quite deterministic approach provided your buffering is not too small. Generally you will not be able to analyze paths of complex hardware/software like disk-subsystems in a GPOS to the point were you can give absolute guarantees - what you can achieve though is statistic guarantees, and in combination with monitoring of the cached data you can (atleast for some access patters) give guarantees about the behavior of the system. hofrat RAT http://www.osadl.org/Papers.rtlws-2004-papers.0.html#PAPER_2590 RTLFS http://www.osadl.org/Papers.rtlws-2004-papers.0.html#PAPER_1889 -- 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
