Xorg input thread (2)

[Tiago Vignatti]

Jesse Barnes escreveu:
> Well, the curious thing was what Tiago said:
> 
>> with or without the input thread when I mlock some mice
>> functions I obtained an unbelievable smooth movement
> 
> Which would imply that when SIGIOs are sent, the process is woken up and can 
> process things just fine, even if other pages are still coming in from disk 
> (I didn't think this was possible, I'd have to poke around the kernel).

Just to be clear, the current input thread is not using SIGIO. It's only 
using a poll(2) to monitor the device's sockets.

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

> 
>> Can we determine whether the thread is actually blocked waiting for one
>> of its pages to get read back in?
> 
> Well, if it's in D state, it's either that or writing out to the X 
> log.  /proc/<pid>/wchan might give us a hint too.  A tool like systemtap 
> would make finding out for sure pretty easy too.

This seems very interest. I'll check this one and answer precisely the 
above Jesses's doubt telling when I X server mlock'd go to D state or not.

>>> Threads (on Linux at least) are fairly lightweight, so even on embedded
>>> systems the added thread shouldn't be too much of a burden.  I think the
>>> DRM based solution would be even nicer for embedded systems though.
>> We were rather hoping to avoid adding the complexities of the connection
>> between input device and output device to the kernel though.
> 
> With a suitable in-kernel API and a new interface it shouldn't be too bad.  
> But it might be more than Tiago is willing to tackle for his SoC project. :)

Daniel said to me that the SoC's intention on Xorg Foundation is not 
just to deliver the product itself, but to learn something about X and 
to keep the collaboration scheme after the project is over. So, while I 
have time I'll be certainly doing all of this :)

I really thank you about all these mails. It was very helpful. Now I 
must reorganize my next steps. Please, help me with it:

a. Initially I think that you had discarded mlock. But now I'll invest 
time on this and come with more exactly values of experimentation.

b. try to investigate a little the DRM/DRI things towards something like
the Ultrix systems which Keith talked. Keith, could you point where can 
we find that old Ultrix code which you mentioned?

c. can you point me something else?


Thanks again and regards

-- 
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br