Re: The performance and behaviour of the anti-fragmentation related patches

Rik van Riel
2007-03-04T01:59:26Z

Andrew Morton wrote:
> On Sat, 03 Mar 2007 20:26:15 -0500 Rik van Riel <riel@redhat.com> wrote:
>> Nick Piggin wrote:
>>
>>> Different issue, isn't it? Rik wants to be smarter in figuring out which
>>> pages to throw away. More work per page == worse for you.
>> Being smarter about figuring out which pages to evict does
>> not equate to spending more work. One big component is
>> sorting the pages beforehand, so we do not end up scanning
>> through (and randomizing the LRU order of) anonymous pages
>> when we do not want to, or cannot, evict them anyway.
>>
>
> My gut feel is that we could afford to expend a lot more cycles-per-page
> doing stuff to avoid IO than we presently do.

In general, yes.

In the specific "128GB RAM, 90GB anon/shm/... and 2GB swap" case, no :)

> At least, reclaim normally just doesn't figure in system CPU time, except
> for when it's gone completely stupid.
>
> It could well be that we sleep too much in there though.

It's all about minimizing IO, I suspect.

Not just the total amount of IO though, also the amount of
pageout IO that's in flight at once, so we do not introduce
stupidly high latencies.

--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.