| |||||||||||||
Page-based direct I/OPage-based direct I/OPosted Aug 28, 2009 2:55 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: Page-based direct I/O by quotemstr Parent article: Page-based direct I/O Thanks for pointing out fadvise; I forgot about it. That's probably a better option than having the application choose the actual cache behavior. But I believe most users of direct I/O today need a new option to get what they want. NOREUSE says "I'm not going to access this data again soon," but we also need, "I don't have anything better to do than wait for I/O, so don't buffer writes on my account." The beauty of this, as opposed to direct I/O, is the kernel can still do readahead and write behind in order to do more efficient disk scheduling, which is something the application really isn't in a position to do -- a user of a filesystem isn't supposed to know anything about seeks and such.
(Log in to post comments)
Page-based direct I/O Posted Sep 7, 2009 10:34 UTC (Mon) by jlokier (guest, #52227) [Link]
When doing video streaming on small embedded systems (small = 32MB RAM, slow processor, no MMU), kernel read-ahead and write-behind turn out to be problematic because they cause too much memory pressure and in a rather lumpy way (which is the real problem - memory allocation failures start happening, and the I/O rate is very variable from one second to the next).
But not having read-ahead and write-behind makes latency too high, unless asynchronous I/O is used to keep the queues full. Asynchronous I/O doesn't work on Linux except with direct I/O. So we're dabbling in asynchronous, direct I/O for video streaming on small devices to make it more reliable.
|
|||||||||||||