Re: [resent PATCH] Re: very slow parallel read performance

From: Daniel Phillips (phillips@bonn-fries.net)
Date: Mon Aug 27 2001 - 13:54:48 EST


On August 27, 2001 06:55 pm, David Lang wrote:
> with you moving things to the inactive queue both when they are used and
> when they spillover from the readahead queue I think you end up putting to
> much preasure on the inactive queue.

Note: the whole point is to avoid having the readahead queue spill over, by
throttling readahead. So the readahead queue should only need to be culled
due to a rise in page activations, enlarging the active list, and requiring
the system to rebalance itself. I don't think you can really talk about
pressure being exerted on the inactive queue by the readahead queue. The
size of the inactive queue doesn't really matter as long as it isn't too
short to provide a good test of short-term page activity. (If it gets very
long then it will automatically shorten itself because the probability of a
given page on the queue being referenced and rescued goes up.)

> given that the readahead queue will fill almost all memory when things
> start spilling off of it you are needing to free memory, so if you just
> put it on the inactive queue you then have to free an equivalent amount of
> space from the inactive queue to actually make any progress on freeing
> space.

Sure, there is an argument for stripping buffers immediately from culled
readahead pages and moving them straight to the inactive_clean list instead
of the inactive_dirty list. In effect, culled readahead pages would then
rank below aged-to-zero and used-once pages. It's too subtle a difference
for me to see any clear advantage one way or the other. Doing it your way
would save one queue-move in the lifetime of every culled readahead page.

--
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