Moving the mouse handling code into a separate thread

(In a puny attempt to write my SoC project progress to my mentor, I
decided to expand it and share my thoughts with you)

Today, we have two methods to register the pointer devices on Xorg
: (1) under SIGIO and (2) put they fd on EnableDevices set.
There is also the silken mouse concept, which means updates fired during
sigio handler (in the case of hw cursor).

We always try to prioritize silken – i.e. when the device emits a move
event, it will be “painted” on the screen and the WaitFor loop still
continue sleeping on select() – But the problem with SIGIO is that it
can blocks if the main thread is wedged doing kernel stuff (like
paging). It can’t interrupt a program in D state.

So, the basically idea is to do a separate thread which takes care the
mouse handling code without using SIGIO. I did an approach and some
questions were raised up:

(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.

(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?

(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.

(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?

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:

I’ll really appreciate comments.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s