Hi all, I'm working on a user-space adaptive readahead daemon (http://preload.sf.net/). I've got a bunch of questions about how kernel handles readahead, mincore, and madvise syscalls though. First is that why (according to my experiements) the readahead syscall is not async? If I want to readahead 200 files, I believe somehow queueing them all should give a better performance than calling readahead on one, waiting for it to be read, calling on the next. Isn't that true? I see that in the readahead package in Fedora, it uses e2fs library to read the position of the first block of the file on disk and uses that to sort files according to the first block, and readahead(2)s them in that order. Does it mean that aio_read may be more effective in some situations? I know that readahead doesn't copy data to userspace, but that shouldn't be a huge advantage, compared to possible seek times that can be saved. What's the deal? The other question is whether madvise is synchronous or async? If it's async, can it be used instead of readahead? What's the algorithm implemented? And another madvise question: If a file X has been used recently, but now my daemon figures out that the application using it is terminated and it's not expected to be needed in the future, is there anyway to tell kernel to get read of it from the page cache? I mean, does calling madvise(MADV_DONTNEED) on a map that is not needed by any other process, free the pages allocated by the map, or it's just LRU still? And one last one, how do mmap, madvise, and mincore syscalls affect the LRU order? Do they freshen the pages in cache? My daemon doesn't currently use those calls, but they may prove useful, does that affect the cache policy? Thanks, --behdad http://behdad.org/ -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
