I have all that. See handle_ra_thrashing() in
http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.6-pre2/dallocbase-10-readahead.patch
> 4) slowly growing the readahead window when there is
> enough memory available, in order to minimise the
> number of disk seeks
>
> 5) the growing in (3) and shrinking in (4) mean that
> the readahead size of all streaming IO in the system
> gets automatically balanced against each other and
> against other memory demand in the system
Doesn't work.
Ah, this is hard to describe.
umm.
a) Suppose that we're getting readahead thrashing. readahead
pages are getting dropped. So we keep seeking to each
file to get new data, so we do a ton of seeking.
b) Suppose that we nicely detect thrashing and reduce the readahead
window. Well, we *still* need to seek to each file to read
some blocks.
See? They're equivalent. In case a) we're doing more (pointless)
I/O, but the cost of that is vanishingly small because it's just
one request.
So what *is* a solution. Well, there's only so much memory available.
In either case a) or case b) we're "fairly" distributing that memory
between all files. And that's the problem. *All* the files have too
small a readahead window. Which points one at: we need to stop being
fair. We need to give some files a good readahead window and others
not. The "soft pinning" which I propose with GFP_READAHEAD and
PG_readhead might have that effect, I think.
I'll try it, see how it feels.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/