On Mon, 23 Apr 2007, Nick Piggin wrote:
> > If you have a single client, the X server is *not* more important than the
> > client, and indeed, renicing the X server causes bad patterns: just
> > because the client sends a request does not mean that the X server should
> > immediately be given the CPU as being "more important".
>
> If the client is doing some processing, and the user moves the mouse, it
> feels much more interactive if the pointer moves rather than waits for
> the client to finish processing.
.. yes. However, that should be automatically true if the X process just
has "enough CPU time" to merit being scheduled to.
Which it normally should always have, exactly because it's an
"interactive" process (regardless of how the scheduler is done - any
scheduler should always give sleepers good latency. The current one
obviously does it by giving interactivity-bonuses, CFS does it by trying
to be fair in giving out CPU time).
The problem tends to be the following scenario:
- the X server is very CPU-busy, because it has lots of clients
connecting to it, and it's not getting any "bonus" for doing work for
those clients (ie it uses up its time-slice and thus becomes "less
important" than other processes, since it's already gotten its "fair"
slice of CPU - never mind that it was really unfair to not give it
more)
- there is some process that is *not* dependent on X, that can (and does)
run, because X has spent its CPU time serving others.
but the point I'm trying to make is that X shouldn't get more CPU-time
because it's "more important" (it's not: and as noted earlier, thinking
that it's more important skews the problem and makes for too *much*
scheduling). X should get more CPU time simply because it should get it's
"fair CPU share" relative to the *sum* of the clients, not relative to any
client individually.
Once you actually do give the X server "fair share" of the CPU, I'm sure
that you can still get into bad situations (trivial example: make clients
that on purpose do X requests that are expensive for the server, but are
cheap to generate). But it's likely not going to be an issue in practice
any more.
Scheduling is not something you can do "perfectly". There's no point in
even trying. To do "perfect" scheduling, you'd have to have ESP and know
exactly what the user expects and know the future too. What you should aim
for is the "obvious cases".
And I don't think anybody really disputes the fact that a process that
does work for other processes "obviously" should get the CPU time skewed
towards it (and away from the clients - not from non-clients!). I think
the only real issue is that nobody really knows how to do it well (or at
all).
I think the "schedule by user" would be reasonable in practice - not
perfect by any means, but it *does* fall into the same class of issues:
users are not in general "more important" than other users, but they
should be treated fairly across the user, not on a per-process basis.
Linus
-
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]
