I don't think it's really bad for system responsiveness. I think the
problem is just that the sample is too small. The proof is that simply
doing sleep_time %= HZ cures most of my woes. WRT contest and it's
io_load, applying even the tiniest percentage of a timeslice penalty per
activation and no other limits _dramatically_ affects the benchmark
numbers. (try it and you'll see. I posted a [ugly but useful for
experimentation] patch which allows you to set these things and/or disable
them from /proc/sys/sched)
I'm trying something right now that I think might work. I set
MAX_SLEEP_AVG to 10*60*HZ , start init out at max, and never allow it to
degrade. Everyone else is subject to boost and degradation, with the
maximum boost being MAX_SLEEP_AVG/20 (which is still a good long sleep, and
the max that one sleep can boost you is one priority). When you start a
cpu hogging task, it should drop in priority just fine, and rapid context
switchers shouldn't gain such an advantage. We'll see. Tricky part is
setting CHILD_PENALTY to the right number such that fork()->fork() kind of
tasks don't drop down too low and have to crawl back up. Contest falls
into this category.
Anyway, I think that inverting the problem might cure most of the symptoms ;-)
-Mike
-
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/