Ken Brownfield wrote:
>
> After more testing, my original observations seem to be holding up,
> except that under heavy VM load (e.g., "make -j bzImage") the machine's
> overall performance seems far lower. For instance, without the patch
> the -j build finishes in ~10 minutes (2x933P3/256MB) but with the patch
> I haven't had the patience to let it finish after more than an hour.
>
> This is perhaps because the vmscan patch is too aggressively shrinking
> the caches, or causing thrashing in another area? I'm also noticing
> that the amount of swap used is nearly an order of magnitude higher,
> which doesn't make sense at first glance... Also, there are extended
> periods where idle CPU is 50-80%.
>
> Maybe the patch or at least its intent can be merged with Andrea's work
> if applicable?
>
> Thanks,
> --
> Ken.
> brownfld@irridia.com
>
Ken,
Attached is an update to my previous vmscan.patch.2.4.17.c
Version "d" fixes a BUG due to a race in the old code _and_
is much less agressive at cache_shrinkage or conversely more
willing to swap out but not as much as the stock kernel.
It continues to work well wrt to high vm pressure.
Give it a whirl to see if it changes your "-j" symptoms.
If you like you can change the one line in the patch
from "DEF_PRIORITY" which is "6" to progressively smaller
values to "tune" whatever kind of swap_out behaviour you
like.
Martin
-
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 : Tue Jan 15 2002 - 21:00:37 EST