Xorg input thread (2)

[Jesse Barnes]

On Thursday, July 5, 2007 8:05:32 pm Tiago Vignatti wrote:
> 2) heavy memory loads
>
> Under heavy memory usage we've got two problems: the X server process in
> the uninterruptible sleep ('D' state)  and some parts of the server
> getting paged to the disk (which leads to the first). These two problems
> happens when all the physical memory has ended up.
>
> The good news: since my approach of implementation is not using signals
> (SIGIO) in the input thread, the D state problem is the first which is
> over. The bad news here is that I didn't note any performance difference
> on the cursor movement with heavy memory loads :(
>
> Also, different from what was expected, the input thread is paging to
> disk. I tried the Jesse Barnes suggestion [2] to mlock the thread with
> no real success (with or without the input thread when I mlock some mice
> functions I obtained an unbelievable smooth movement. But I know that
> this isn't an elegant solution).

Hm, well if that works well we might consider it.  How much needs to be 
mlocked?  There are mechanisms to allow processes to lock a small amount of 
memory if needed, so if it's not too much, we could mlock instead of using a 
new thread.

> Q: How to reproduce 2)? A: a malloc hog.
>
>
> The small conclusion of 2): if the real focus of the input thread is to
> stop with the cursor's lag then we must provide other ways to keep the
> cursor's footprint in the physical memory. (Should I consider the
> Jesse's suggestion to put this all inside DRM? I really don't know how
> difficult this can be. Jesse, please?)

It shouldn't be too hard, but it'll require changes to the X server (and 
you've already touched those paths so you're familiar with them), each DDX 
driver that supports the feature, and their corresponding kernel DRM drivers.  
My thought was that the DRM driver would take care of the actual cursor blt 
to the screen, based on events it receives from the input layer.  The X 
server and DDX driver would be responsible for loading new cursor images to 
the DRM driver, and processing updated coordinate information, which could be 
sent from the kernel via a shared memory segment or some other mechanism.

> Also, if we're running to achieve the 2) solution, the real interest
> will be systems with few memory (embedded and so on)? On this mobile
> systems people active the swap all the time (the OLPC's laptop not,
> right?)? This leads to other question: would really advantageous to do
> the input thread only having in mind tiny systems?

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.

Thanks for doing all this, keep it up!

Thanks,
Jesse