* Linus Torvalds <[email protected]> wrote:
> > 4 0 0 475752 13492 176320 0 0 0 0 107 1477 85 15 0 0 0
> > 4 0 0 475752 13492 176320 0 0 0 0 122 1498 84 16 0 0 0
>
> Did you even *look* at your own numbers? Maybe you looked at
> "interrpts". The context switch numbers go from 170 per second, to
> 1500 per second!
i think i managed to look at the correct column :) 1500 per second is
the absolute ceiling under CFS.
but, even though this utterly ugly hack of renicing (Arjan immediately
slapped me for it when i mentioned it to him and he correctly predicted
that lkml would go amok on anything like this) undeniably behaves better
under CFS and gives a _visually better_ desktop at a 1500 context
switches per second, i share your unease about it on architectural and
policy grounds. Doing this hack upstream could easily hinder the
efficient creation of a healthy economy for "scheduler money", by
forcibly hacking X out of the picture - while X could be such a nice
(and important) prototype for a cool and useful new scheduling
infrastructure.
Basically this hack is bad on policy grounds because it is giving X an
"legislated, unfair monopoly" on the system. It's the equivalent of a
state-guaranteed monopoly in certain 'strategic industries'. It has some
advantages but it is very much net harmful. Most of the time the
"strategic importance" of any industry can be cleanly driven by the
normal mechanics of supply and demand: anything important is recognized
by 'people' as important via actual actions of giving it 'money'. (This
approach also gives formerly-strategic industries the boot quickly, were
they to become less strategic to people as things evolve.)
still, recognizing all the very real advantages of a cleaner approach,
my primary present goal with CFS is to reach "maximum interactivity"
here and today on a maximimally broad set of workloads, whatever it
takes, and then to look back and figure out cleaner ways while still
carefully keeping that maximum interactivity propertly of CFS.
For this particular auto-renicing hack here are the observed objective
advantages to the user:
1) while it's still an ugly hack, the increased context-switching rate
(surprisingly to me!) still has actual, objective, undeniable
positive effects even in this totally X-centric worst-case messaging
scenario i tried to trigger:
- visibly better eye-pleasing X behavior under the same
"performance of scrolling"
- no hung mouse pointer. Ever. I'd not go as far as Windows to
put the mouse refresh code into the kernel, but now having
experienced under CFS the 'mouse never hangs under any load'
phenomenon for a longer time, i have to admit i got addicted
to it. It give instant emotionally positive feedback about
"yes, your system is still fine, just overworked a bit", and
it also gives a "you caused something to happen on this box,
cool boy!" reassurance to the impatient human who is waiting
on it - be it that such a minimal thing as a moving mouse
pointer.
There's a new argument as well, not amongst the issues i raised
before: people are happily spending 40-50% of their CPU's
power on Beryl just to get a more ergonomic desktop via 3D effects,
so why not allow them to achieve another type of visual ergonomy by
allowing an increased, maximum-throttled X context-switch rate,
without any measurable drop in performance, to a tunable maximum?
I can see no easy way for X itself to control this context-switching
"refresh" rate in a sane way, as its workload is largely detached
from client workloads and there's no communication between clients.
2) it's the absolute worst maximum rate you'll ever see under CFS, and
i definitely concentrated on triggering the worst-case. On other
schedulers i easily got to 14K context-switches per second or worse,
depending on the X workload, which hurts performance and makes it
behave visually worse. On CFS the 1400 context-switches is the
_ceiling_, did not measurably hurt performance and it is tunable
ceiling.
3) this behavior was totally uncontrollable on other schedulers i tried
and indeed has hurt performance there. On CFS this is still totally
tunable and controllable on several levels.
i'm not saying that any of this reduces the ugliness of the hack, or
that any of this makes the strategic disadvantages of this hack
disappear, i simply tried to point out that despite the existing
conventional wisdom it's apparently much more useful in practice on CFS
than on other schedulers.
And if the "economy of scheduling" experiment fails in practice for some
presently unknown technological reason, we might as well have to go back
to ugly tricks like this one. With its 5 lines and limited scope i think
it still beats 500 lines of convoluted scheduling heuristics :-/ Right
now i'm very positive about the "economy of scheduling" angle, i think
we have a realistic chance to pull it off.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
