Jim Gettys writes: > Most operating schedulers are much happier to give you the CPU > again if you don't monopolize the CPU, and let the other processes > get the CPU regularly. Generally, they boost the priority > of processes that just use a short amount of CPU, and then > give it back. > > This is typical "interactive" behavior of processes. > > Having the X server yield if it is busy is a good thing to do.
Yes, I agree that there are situations where this is true. However there is not guaranteed latency. In some situations normal rescheduling just isn't enough. We'd need to get rescheduled on a certain event within a certain time window. As long as we don't have the infrastructure for that we need to loop. > > Most workstation based X servers have had a shared queue/pipe > with the driver, fill up that queue, and arrange in the driver > at interrupt level to set up the next set of commands or image > transfers (to keep the hardware busy), and then the OS would > typically schedule the X server process again (which would > refill the command buffers). In many operating systems, > there were ways to tell the operating system in the driver that > the process should be woken up. That is with a driver component in the kernel I suppose. > > Having the X server busy wait in user mode for any significant time > is a bad idea... That is definitely true. I agree that we should have some level of kernel support. It however needs to be implemented in a way that the driver will continue to build and work on OSes where this kernel support isn't available. This is one item I would like to experiment with on my (long) list of TODOs. > > Note that this equation has been changing in Linux greatly > recently: until very recently Linux has had a sucky scheduler > and has only recently started to use an O(1) scheduler like most > BSD Unix systems have had for aeons (20 years). But also note > that Linux has been working very hard the last couple years > in general on removing latency. That's definitely true, but in these situations we have a harder RT requirement. Egbert. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
