On Thu, 7 Mar 2002, Andrew Morton wrote:
> > 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.
Actually, it could boil down to something more:
use-once reduces the VM to FIFO order, which suffers from
belady's anomaly so it doesn't matter much how much memory
you throw at it
drop-behind will suffer the same problem once the readahead
memory is too large to keep in the system, but at least the
already-used pages won't kick out readahead pages
regards,
Rik
-- <insert bitkeeper endorsement here>http://www.surriel.com/ http://distro.conectiva.com/
- 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/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:01:10 EST