> > i've changed it back to 15 around pre9-2.2.0. Your original reasoning for
> > reducing PROC_CHANGE_PENALTY was interactive feel, but this became a
> > non-issue with my smp_reschedule patches, so i empirically adjusted
> > PROC_CHANGE_PENALTY to maximize kernel compilation speed.
>
> Ah the irony... My patch for 2.1.131 changed it to 15, but Linus chose
> 10 :-)) Lucky guess!
>
> I must read the new scheduling code and try to figure out the effects of
> smp_reschedule(). I wasn't aware that it removed the interactive
> problem. Also note that I changed it from *20* to 15, so don't be
> completely sure you've killed the interactive problem unless it's gone
> when you build a kernel with it set to 20. Basically, due to the nature
> of the problem, even reducing it to 19 was enough to prevent it hurting
> interactive response time.
(yes but the real interactive problems were still there. It's a whole
different issue, PROC_CHANGE_PENALTY is now only a way to measure
processor changing penalty, without any interactivity issue.) I have made
it a sysctl and i've tried lots of settings (including 20), and for pure
CPU-intensive work (kernel compilation) 15 proved to be the best.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/