Xorg input thread (2)
jbarnes at virtuousgeek.org
Fri Jul 6 17:21:59 PDT 2007
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  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
> 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!
More information about the xorg