| |||||||||||||
I want something similarI want something similarPosted Feb 24, 2005 17:00 UTC (Thu) by ncm (subscriber, #165)Parent article: Flushing the page cache from user space To me, and to most of us, a much more helpful feature would be a way to identify inodes whose pages should not be cached at all. So that it could be used by unprivileged processes, the effect might apply only for the current process: pages seen by another process from that inode would still stick in the cache, and the current process would still use those, but reads or writes (or unmappings) it initiates would wash out of the cache immediately. We might also, or instead, have an attribute stored on the inode to identify an uncached file. Then, most programs wouldn't need to know about the feature. Tar and xine might be good examples of programs that should know about, or at least benefit from, such a feature.
(Log in to post comments)
I want something similar Posted Feb 24, 2005 18:09 UTC (Thu) by jsbarnes (guest, #4096) [Link] fadvise and madvise could provide this feature for programs like tar &xine. madvise(addr, len, MADV_DONTNEED) will tell the kernel that a given virtual address range is unlikely to be accessed again anytime soon, and I believe there's an equivalent for files as well.
I want something similar Posted Mar 13, 2005 18:16 UTC (Sun) by farnz (guest, #17727) [Link] posix_fadvise already provides that functionality. posix_fadvise(fd,0,0,POSIX_FADV_NOREUSE); will tell the kernel that each byte of a file is only accessed once, while posix_fadvise(fd,start,len,POSIX_FADV_DONTNEED); will tell the kernel that a particular range of data is finished with.Apart from developer time, there's no real reason not to use posix_fadvise and posix_madvise (the equivalent for memory mapped objects); if the kernel doesn't handle them, they get ignored, and they make it possible for the kernel to do more intelligent caching if it does understand them.
|
|||||||||||||