Messages in this thread | | | Date | Fri, 10 Mar 2000 01:17:21 -0500 | Subject | Re: Linux responsiveness under heavy load | From | tytso@MIT ... |
| |
Date: Wed, 08 Mar 2000 16:33:48 -0700 From: "Jeff V. Merkey" <jmerkey@timpanogas.com>
FYI. Earlier versions of Windows NT had this same problem (and it still does). The way they got around it was to "cheat" by cranking up the priority of the console an Windows GUI subsystem anytime someone hit a key or moved the mouse. In fact, an NT server is still heavily loaded, but by making the display look and feel "snappy", it presents the illusion that the server has great responsiveness under heavy load. This stuff in NT is all hard coded (Since their GUI is tightly integrated with the OS), and if Linux wanted to do the same, the X Server and bash would probably be the places to do this .....
I wouldn't call this cheating at all. There are a number of classical tradeoffs that you have to contend with when doing scheduler design. One is the tradeoff between efficiency and responsiveness. Switching between tasks costs, and so if you have a very heavily loaded batch system, it's most effiencient to set the scheduling quantuum very high, so that a process runs for long periods of time before some other process runs. On the other hand, for a desktop system, where user interaction is important, you want to set the scheduling quantuum as short as possible.
Linux does something similar, in terms rewarding processes that give up their timeslice before their scheduling quantuum is up, and giving less priority to CPU-bound processes. NT is simply taking it to the next level, and rewarding user-interaction more than other I/O bound processes. Since NT doesn't have an X server, they have to bump up the priority of the W32 subsystem when it's in the middle of doing graphics. The equivalent analogue for us on the Unix side is to run the X server at a slightly high priority. (Say, nice -4).
This isn't cheating; it's just making a policy statement that user interaction is more important that some of the other things that the machine might be doing. If a 10 minute kernel compile takes an extra 10 seconds to complete, it's not a big deal. But if mouse motion and keyboard response takes an extra 10 milliseconds, it is a very big deal as far as the user is concerned.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |