On Wed, 8 Aug 2001, Marcelo Tosatti wrote:
>
> Testing.
Btw, after doing the math I can already tell you that the constraints this
patch puts on "free" memory are much too aggressive.
We should let the inactive_clean numbers grow much more than this patch
does - the plenty-limit for "inactive" pages (ie "zone_inactive_plenty()"
is a hefty "zone->size/3", and I think the plenty-limit for "free" pages
should be noticeably higher than just "zone->pages_high".
Right now pages_high defaults to (zone->size / 128) * 3, so with the patch
we basically stop laundering a zone when it has 2.5% inactive_clean +
outright free pages. Which is fairly obviously hugely bogus now that I
actually did the math ;)
The current patch "zone_free_plenty()" logic also happens to be just at
the corner of what __alloc_pages() thinks is good, so the anti-hysteresis
doesn't actually end up working in that sense - we end up bouncing around
that magic "pages_high" value.
Rik, Marcelo, any suggestions on less obviously bogus "plenty" values?
My personal "random number" would be to just to multiply that limit by
two, and make the plenty test say that we have enough free if we have more
than 2*zone->pages_free.
I also think that 5% "free or really easily freeable" sounds a bit more
reasonable than 2.5%.
Comments?
Linus
-
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 : Wed Aug 15 2001 - 21:00:14 EST