Re: The performance and behaviour of the anti-fragmentation relatedpatches
From: Rik van Riel
Date: Sat Mar 03 2007 - 20:59:40 EST
Andrew Morton wrote:
On Sat, 03 Mar 2007 20:26:15 -0500 Rik van Riel <riel@xxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/