| |||||||||||||
Page-based direct I/OPage-based direct I/OPosted Aug 28, 2009 2:05 UTC (Fri) by quotemstr (subscriber, #45331)In reply to: Page-based direct I/O by giraffedata Parent article: Page-based direct I/O
Linux doesn't offer what they really want: simply a cache replacement policy that says, "try not to keep anything for this file in cache." posix_fadvise(fd, 0, 0, POSIX_FADV_NOREUSE);
(Log in to post comments)
Page-based direct I/O Posted Aug 28, 2009 2:55 UTC (Fri) by giraffedata (subscriber, #1954) [Link] 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.
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.
|
|||||||||||||