[Xevie] Re: My current design efforts

[Jim Gettys]

Deron,

This smells very unlikely to be context switching overhead: 220 ms is
many *orders of magnitude* more than the basic latency that you,
yourself have measured.  Shared memory just isn't going to make a
difference. I measure .05 ms on my laptop (sync measurement of x11perf).

I do know that on most UNIX/Linux systems there have frequently been
major latency glitches, commonly caused by key kernel locks being held
for extended periods, often on pretty infrequent events (errors,
mounting file systems, etc).

There has been *major* work over the last two years on Linux to reduce
these problems, (and on Linux 2.6 kernels, this behavior is pretty
rare), and the community is still working further in this area.

On many 2.4 kernels, this behavior would not be unusual; and many
commercial UNIX systems I've seen similarly bad (or worse) behavior.
Without fixing the kernel, you just can't fix the latency variation,
and 220ms is beyond the pale.

				Regards,
					- Jim
 
> 
> I've done some timing studies on the cost of the initial round trip from
> the X Server -> Display Server -> X server. The incremental latency
> overhead is negligible most of the time (around 0.25 ms). But
> occasionally I measure an overhead spike of about 220 ms. This blows
> by latency budget (which is about 20-30ms per event). I suspect that
> these spikes are due to context switching between the Display Server and
> the X server but I haven't yet proved it. If this is the case, then I
> may be able to tune the Display Server kernel thread priorities to
> minimize this problem. But at this point I still haven't ruled out the
> use of shared memory to help solve the problem. If I can't reduce the
> latency spikes then I may need to revert to my previous design of doing
> the grab processing over in the Display Server. But rather than shipping
> window hierarchy information from the X server to the Display Server
> using the event channel, I may try to introduce shared memory access
> to the window hierarchy itself. I hope that I don't have to go this
> route, but I'm not yet sure enough of the Z model to eliminate the
> need for a backup plan.
> 
> _______________________________________________
> xevie mailing list
> xevie at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xevie