> There have been several replies to my comment that madvise() in Solaris
> doesn't do much. I'd like to clariy a bit.
> . madvise(.. SEQUENTIAL ..) and madvise(.. RANDOM ..) don't do
> much in SunOS (in fact, I think they do nothing). Unless
> things have changed in Solaris, that's still true.
> . madvise(.. WILLNEED ..) may have done prefetches but I don't think
> so, I'm pretty sure it was left in as a hook in case they needed
> it in the future.
> . madvise(fd, off, length, WONTNEED) turns into a
> VOP_PUTPAGE(vp, off, length, ...) which throws the pages away.
I think your knowledge of Solaris is probably out of date. I have
done a few tests on 2.5.1:
$ ./readaheadtest
Usage: readaheadtest number-of-points file-to-read m|a|n
m: Just mmap
a: Mmap and use MADV_SEQUENTIAL
n: Mmap and use MADV_WILLNEED
d: Mmap and use MADV_WILLNEED and MADV_DONTNEED
eg: time readaheadtest 2 /tmp/hugefile m
$ time ./readaheadtest 2 ../mandel/sparc/hook2.eps m
Without SEQUENTIAL, without WILLNEED, without DONTNEED:
87719936 bytes (85664k, 83M) read
real 3m38.97s
user 0m2.85s
sys 0m6.60s
$ time ./readaheadtest 2 ../mandel/sparc/hook2.eps a
With SEQUENTIAL, without WILLNEED, without DONTNEED:
87719936 bytes (85664k, 83M) read
real 0m40.98s
user 0m2.38s
sys 0m4.66s
$ time ./readaheadtest 2 ../mandel/sparc/hook2.eps n
Without SEQUENTIAL, with WILLNEED, without DONTNEED:
87719936 bytes (85664k, 83M) read
real 0m34.81s
user 0m2.78s
sys 0m4.77s
$ time ./readaheadtest 2 ../mandel/sparc/hook2.eps d
Without SEQUENTIAL, with WILLNEED, with DONTNEED:
87719936 bytes (85664k, 83M) read
real 0m16.77s
user 0m2.94s
sys 0m7.02s
The times are not all that stable, but the trend is clear.
Madvise works on Solaris, quite well, actually.
The same test on a 2.0.32 box gives:
$ time ./readaheadtest 2 /mnt/redhat/bigfile m
Without SEQUENTIAL, without WILLNEED, without DONTNEED:
87719936 bytes (85664k, 83M) read
2.81user 2.75system 3:49.12elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (43329major+18minor)pagefaults 9swaps
Which is very bad, but to be expected as Alan says there is
no readahead on mmap on 2.0.
I imagine that this test is quite sensitive to the size of your
hard disks internal cache. If your hard disk has space for several
complete tracks in the internal cache it might do readahead for you.
You can counteract this by increasing the number of points to read
in the file.
You can find the test program on
http://www.image.dk/~ehcorry/linux/readaheadtest.c
-- Erik Corry erik@arbat.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu