On August 27, 2001 04:42 pm, Alex Bligh - linux-kernel wrote:
> --On Monday, 27 August, 2001 4:31 PM +0200 Daniel Phillips
> <phillips@bonn-fries.net> wrote:
>
> > - Readahead cache is important enough to get its own lru list.
> > We know it's a fifo so don't have to waste cycles scanning/aging.
> > Having a distinct list makes the accounting trivial, vs keeping
> > readahead on the active list for example.
>
> A nit: I think it's a MRU list you want. If you are reading
> ahead (let's have caps for a page that has been used for reading,
> as well as read from the disk, and lowercase for read-ahead that
> has not been used):
> ABCDefghijklmnopq
> | |
> read disk
> ptr head
> and you want to reclaim memory, you want to drop (say) 'pq'
> to get
> ABCDefghijklmno
> for two reasons: firstly because 'efg' etc. are most likely
> to be used NEXT, and secondly because the diskhead is nearer
> 'pq' when you (inevitably) have to read it again.
Good point. Even with a fifo queue we can deal with this nicely by modifying
the insertion step to scan forward past other pages of the same file. So the
readahead pages end up being inserted in reverse order locally, while
chunkwise we still have a fifo.
> This seems even more imporant when considering multiple streams,
> as if you drop the least recently 'used' (i.e. read in from disk),
> you will instantly create a thrashing storm.
The object is to avoid getting into the position of having to drop readahead
pages in the first place, by properly throttling the readahead. When we do
have to drop readahead it's because the active list expanded. Hopefully we
will stabilize soon with a shorter readahead list. Yes, it may well be
better to drop from the head of the queue instead of the tail because the
dropped pages will come from a smaller set of files. On the other hand, we
will penalize faster streams that way. Furthermore, sometimes readahead
pages may never be used in which case we would keep them forever.
> And an idea: when dropping read-ahead pages, you might be better
> dropping many readahed pages for a single stream, rather than
> hitting them all equally, else they will tend to run out of
> readahead in sync.
Yes, this requirement is satisfied by the arrangement described.
-- Daniel - 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 : Fri Aug 31 2001 - 21:00:24 EST