Xorg input thread (2)
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.
C3SL - Centro de Computação Científica e Software Livre
More information about the xorg