Xorg input thread (2)

[Tiago Vignatti]

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
www.c3sl.ufpr.br