On Thursday 06 March 2003 12:35 pm, Linus Torvalds wrote:
> On 6 Mar 2003, Alan Cox wrote:
> > Not all X servers do that. X is not special in any way. Its just a
> > daemon. It has the same timing properties as many other daemons doing
> > time critical operations for many clients
>
> I really think that this is the most important observation about the
> behaviour. X really isn't doing anything that other deamons don't do. It
> so happens that what X is doing is a lot more complex than most deamons
> do, so it's fairly easy to trigger X into using a fair amount of CPU time,
> but that only makes the breakdown case so much easier to see.
>
> In all honesty, though, it's also obviously the case that the breakdown
> case in the case of X is _really_ visible in a very very concrete way,
> since X is the _only_ thing really "visible" unless you have Direct
> Rendering clients. So even if the problem were to happen with another
> deamon, it probably wouldn't stand out quite as badly. So in that sense X
> ends up having some special characteristics - "visibility".
Yes. The special thing about X (and XMMS, XINE, et al) is that the
interactivity heuristic fails in a user-noticeable way. The heuristic must
also be guessing incorrectly in other situations, but nobody seems to have
noticed when it did (or, at least, complained about it).
Another noteworthy attribute of these programs is that they _know_ they will
be used interactively. And, if there were a way for them to convey that
information to the kernel (not by using 'nice'), I bet all of the above
projects would take advantage of that mechanism.
At first I strongly dissaproved of the kernel's timeslice adjustment by
interactivity estimation; policy belongs in userland, I thought. But the
algorithm is actually quite effective -- a balance between high HZ for
real-time-ish applications but manages to avoid the cache-thrashing in places
it would hurt. This policy works well most of the time, so the kernel
includes it as a sensible default. But X demonstrates that sometimes we want
to set a different policy. After all, the heuristic will not become perfect,
and its worst-case behavior is pretty bad. (If your computers are too fast
to notice, try turning off cache with /proc/mtrr. Not be a great idea on an
important system though...)
The question is: what interface would be used? A new syscall seems excessive;
but something in /proc (/proc/xyz/preferred_timeslice ?) is non-optimal,
because it must not be used in chroot. I am not qualified to suggest the
Proper mechanism, but I strongly believe there should be one.
--Eric
-
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 : Fri Mar 07 2003 - 22:00:34 EST