On Sun, Jul 15, 2001 at 12:00:38PM -0500, Troy Benjegerdes wrote:
>
> The next very interesting thing I found was that if I run something like
> 'while true; do true; done' to load the other CPU while gzip is running,
> gzip runs faster. The time change isn't very large, and appears to be just
> barely detectable above the noise, but it definetly appears that gzip is
> bouncing back and forth between cpus if both are idle.
>
> I'm tempted to try the somewhat brute-force approach of increasing
> PROC_CHANGE_PENALTY, which is currently set to 20 (on ppc) to something
> like 100. Would this be an adequate 'short-term' solution util there is
> some sort of multi-queue scheduler that everyone Linus likes? What are the
> drawbacks of increasing PROC_CHANGE_PENALTY?
I'm pretty sure changing the value of PROC_CHANGE_PENALTY will not help
in this case. PROC_CHANGE_PENALTY becomes increasingly important as
the number of running tasks is increased. In the case of simply running
one task (like gzip) on your 2 CPU system, I don't think it will make
any difference.
-- Mike Kravetz mkravetz@sequent.com IBM Linux Technology Center - 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 : Sun Jul 15 2001 - 21:00:23 EST