On August 24, 2001 10:19 pm, Rik van Riel wrote:
> On Fri, 24 Aug 2001, Daniel Phillips wrote:
> > On August 24, 2001 07:43 pm, Rik van Riel wrote:
>
> > > 1) under memory pressure, the inactive_dirty list is
> > > only as large as 1 second of pageout IO, meaning
> > ^^^^^^^^
> > This is the problem. In the absense of competition and truly
> > active pages, the inactive queue should just grow until it is
> > much larger than the active ring. Then the replacement policy
> > will naturally become fifo, which is exactly what you want in
> > your example.
>
> Actually, no. FIFO would be ok if you had ONE readahead
> stream going on, but when you have multiple readahead
> streams going on you want to evict the data each of the
> streams has already used, and not all the readahead data
> which happened to be read in first.
We will be fine up until the point that the set of all readahead fills the
entire cache, then we will start dropping *some* of the readahead. This will
degrade gracefully: if the set of readahead is twice as large as cache then
half the readahead will be dropped. We will drop the readahead in coherent
chunks so that it can be re-read in one disk seek. This is not such bad
behaviour.
All this assuming you don't enforce the 1 second size limit on the inactive
queue, of course.
We probably could squeeze a little better performance out of this case by
magically knowing that no input page will ever be reused, as you suggest.
We risk getting such an improvement at the expensive of other, more typical
loads.
That said, I think I might be able to come up with something that uses
specific knowledge about readahead to squeeze a little better performance out
of your example case without breaking loads that are already working pretty
well. It will require another lru list - this is not something we want to do
right now, don't you agree?
-- 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:14 EST