My vote is forget madvise() until we've seen how well the kernel
performs with Chuck's patches. MADV_DONTNEED may well come in handy,
but I'm skeptical about MADV_SEQUENTIAL/MADV_RANDOM.
The read-ahead and clustering mechanism should notice random
vs. sequential very easily, and because the kernel can deduce how fast
the disk is relative to the app., it can tune the windows sizes
optimally as well.
For that sort of self-tuning algorithm we've been discussing,
madvise(MADV_SEQUENTIAL) makes no difference to the paging algorithm:
you have to track faults in order to discover the tuning parameters
anyway. And the app can't provide that info statically because it
doesn't know how fast the disk/network is.
Which gives me a thought. Is there's an algorithm to discover the
optimal random-access readaround cluster size, analogous to the
sequential readahead window algorithm?
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/