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.
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.
Having the X server busy wait in user mode for any significant time
is a bad idea...
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.
- Jim
On Tue, 2003-09-23 at 06:17, Egbert Eich wrote:
> Mark Vojkovich writes:
> > Can we export to the drivers some function that yields the CPU?
> > Currently alot of drivers burn the CPU waiting for fifos, etc...
> > usleep(0) is not good for this because it's jiffy based and usually
> > never returns in less than 10 msec which has the effect of making
> > interactivity worse instead of better. I'm not sure which platforms
> > don't export sched_yield() and which will need alternative
> > implementations.
> >
>
> I've experimented with sched_yield in drivers when waiting for retrace
> on video playback. It turned out that when the system was otherwise
> idle the video performance was about the same. However when another
> application was using its full time slice the video frame rate would
> drop far below the screen refresh rate.
>
> I've measured the latencies and it turned out that the time elapsed
> before the process would be rescheduled was considerably higher than
> the average time the process was hanging in the wait loop when the
> system was otherwise busy.
> Shorter (or variable) time slices may help here, but a better solution
> would be to use an event (ie. interrupt) driven rescheduling.
> This would require a small kernel support module for each driver,
> though.
>
> Egbert.
> _______________________________________________
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
--
Jim Gettys <[EMAIL PROTECTED]>
HP Labs, Cambridge Research Laboratory
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
