| |||||||||||||
Page-based direct I/OPage-based direct I/OPosted Aug 27, 2009 22:10 UTC (Thu) by giraffedata (subscriber, #1954)Parent article: Page-based direct I/O
Developers use direct memory for either (or both) of two reasons: (1) they believe they can manage caching of file contents better than the kernel can, or (2) they want to avoid overflowing the page cache with data which is unlikely to be of use in the near future. I agree that's what they use it for, but neither of these is really the point of direct I/O. Developers use it for this side effect, because 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." The reasons for direct I/O per se are different. I believe there are two: 1) something besides this kernel image is accessing the file, so there's no way for the user space program and this other thing to synchronize with kernel caching in the mix. 2) you want to save the expense of an extra copy of data through the kernel's cache. (You can get this with mmap too, but it has drawbacks compared to read/write).
(Log in to post comments)
Page-based direct I/O Posted Aug 28, 2009 2:05 UTC (Fri) by quotemstr (subscriber, #45331) [Link] 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);
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.
|
|||||||||||||