Xorg input thread

[Jesse Barnes]

On Friday, June 15, 2007 1:12:19 Tiago Vignatti wrote:
> (1) With (silken/hw cursor) or without the input thread  seems to be
> equal in perfomance (tested with three video cards: ATI Rage XL,
> GeForce FX 5500 and GeForce2 MX/MX 400). I'd tested with a
> gnome-session started and ran 'x11perf -putimagexy500'. The cursor
> never lag the mouse in both situations. At least no performance
> regressions :) Fine.

You could try running it with some sort of memory hog test program to 
generate swapping.  In that case the thread should be a bit better.

> (2) But I think that (1) is not the exactly problem which we're
> trying to solve. Daniel Stone said once to me that having a tiny
> footprint that needs to be kept in memory, it wouldn't need to wait
> to be paged into the active set all the time. Here Daniel's
> transcription: "Currently it works _almost_ like this, but SIGIO is
> in the same process, with a very large memory footprint.  So if any
> part of the X server is waiting to be paged in to memory, then you'll
> be completely blocked on disk I/O.  This is the problem we have
> today: under heavy disk and memory loads, we end up blocked on I/O.
> OTOH, the input thread won't get paged out, because its active set
> will be extremely small". But how to keep this resident? Is it inner
> to the thread?

Well you could mlock it, but the kernel really shouldn't be evicting 
those pages anyway (and if it does, they'll come right back).

> (3) Another thing that is breaking my head is to not have such a
> mechanism to do a real performance test. How to know if the thread
> has advanced or not the overall performance? Maybe using the 'time'
> tool? Maybe something with xtest? I don't know.

Yeah, the only real performance test is to find a situation where poor 
pointer behavior occurs, then see if the thread approach prevents it.

> (4) So far I'm not facing any problem concerning the thread safety.
> Yesterday, on the IRC, Mercury and Clee tell me to test the input
> thread on SMP machines to really do it parallelized. I haven't done
> it yet. Some another tips here?

If you haven't seen corruption yet, it's probably safe, but it would be 
good to run it on an SMP machine just to test some more...

> The input thread (using clone syscall) is on my Linux machine. The
> patch applies with the last git evdev and xserver. You can see it
> here:
>
> http://web.inf.ufpr.br/vignatti/tmp/xorg-input-thread.diff

The actual thread creation will have to go under os-support somewhere, 
since clone() is Linux specific (most Unices have something similar 
though), unless you switch to using pthreads.

I think this is a nice feature, but for DRM supporting OSes, I'm hoping 
we can eventually have pointer movement handled by the kernel at 
interrupt time.  That way even if your box is swapping really badly, 
you'll still get normal pointer response, and you'll know it's not 
hung.  But it means tying the DRM and input subsystems together with a 
new callback scheme (though on Linux we may have one we can reuse) and 
enhancing the DRM drivers to do cursor updates.

Jesse