Xorg input thread (2)

Tiago Vignatti vignatti at c3sl.ufpr.br
Sun Jul 8 23:38:56 PDT 2007

Keith Packard escreveu:
> On Sun, 2007-07-08 at 03:23 -0300, Tiago Vignatti wrote:
>> And Jesse, to be fair, I just tried a little with mlock. I spent more 
>> time  with mlockall (which is much easier to play than mlock) seeing 
>> whether the cursor lags or not. My little results with mlockall 
>> demonstrates that we can obtain a smooth mouse only increasing 3MB of 
>> "always resident memory".
> So, you use MCL_CURRENT to lock the pages present in the server at
> startup time? If so, this could answer the question of whether the
> presence of other paging going on within the X server would affect the
> locked pages used by the mouse thread.

I did a cool experiment here to see the effects of the D state acting on
the X server process when I start it with and without the input thread
and always mlock'ing it.

First I set the grub to start my machine with only 170 mb of physical
memory. Then I put a 'mlockall(MCL_CURRENT)' just before the call of
Dispatch() function, on the main.c. So then I started the server. Well,
I called a memory hog to eat all my physical memory and played with the
mouse which never gets lagged using or not the separate thread. So the
great notice comes when I started an X client (gnome-session) which
turns the X process to the D state. The X server without the separate
thread lags the cursor because it's using SIGIO to wake up the device.
OTOH, the X with the input thread has a smooth movement anyway.

Got it? In summary, I locked to memory all functions until Dispatch is
called and when the X server is in the D state the cursor lags when some
clients connected to X are using blocks which aren't locked. And if
we're using the input thread (consequently not SIGIO) it doesn't lags!

Here the experiments. When I mlockall(MCL_CURRENT) at that point before
Dispatch, the X starts with:
- 7412 kb of resident memory, without the input thread.
- 7412 kb of resident memory, with the input thread, using clone syscall
to create the child process.
- 15 mb of resident memory, with the input thread, using pthread to
create te child process (yeah, pthread really bloats it).

Of course all these 3 values of resident memory above never decreases.
OTHO, without mlock and with, or without, the thread the X starts with
about 4080 kb of resident memory which decreases until about 304 kb. The
first question is: why such a difference of 3 mb when I lock and when I
do not lock the memory used by X?

> If the mouse thread is independent of other X server paging, we could
> (fairly) easily identify all of the functions that are involved in mouse
> motion, place them in a separate ELF segment and then mlock them when
> the server starts. While ugly, this seems fairly non-invasive.

How easily I could identify these functions? I think that I must dig
more this way and study these ELF tricks. Keith, could you please tell
more about it or point me something? Some docs would be good.

best regards

Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre

More information about the xorg mailing list