This is not what I've seen.
When X is interactive, and is competing against other interactive jobs,
you don't get multi-second slowdowns. X still gets 10% of the CPU, it just
gets it in smaller chunks.
The multi-second "freezes" are the thing that bothered me, and those were
definitely due to the fact that X was competing as a _non_interactive
member against other non-interactive members, causing it to still get 10%
of the CPU, but only every few seconds. So you'd get a very bursty
behaviour with very visible pauses.
It's ok to slow X down. Nobody in their right mind would expect X to track
the mouse 100% when scrolling and the machine load is 15+. I certainly
don't.
But having X just _pause_ for several seconds gets to me. I can't easily
make it happen any more thanks to having ridiculous hardware, and I think
X itself has gotten better thanks to more optimizations in both clients
and X itself (ie if the CPU requirements of X go down from 5% to 3%, it
gets a _lot_ harder to trigger).
But it was definitely there. 3-5 second _pauses_. Not slowdowns.
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/