Xorg input thread – summary or something #3

Not so much, but here are the news:

  • For the final evaluation period on the Summer of Code, Daniel suggest me to start my own X server tree. So I’m maintaining this one with the last bits of the X server input thread implementation and always trying to keep all the things up to date with the upstream tree. Everyone is very welcome to test it and report me the few – I expect – bugs.
  • The last new regarding the thread implementation is that we’re unfortunately dealing with critical sections inside the X event queue (mi/mieq.c), so mutex is needed there (just to note: currently, mutex is only implemented using pthread (X11/Xthreads.h), so we also need implement something that is pthread-independent). Probably can exist other pieces of code that might be in an unpredictable way resulting some race conditions (didn’t note anything strange yet!).
  • I finally managed how to implement the page fault notifier without any patch inside the kernel. The read_cr2() can be called directly since the page fault notifier runs with interrupts disabled. The implementation can be found here.

mlock()’ing adventure

It’s being a great adventure to lock the X input thread on the memory. I’m touching a lot of things that I’d never imagined before :)

To trace the pages that are faulting when I move the device pointer I’m using my own ultra mega super kernel’s page fault notifier. It’s very simple, but as the things are not always perfect, it needs a little patch in the kernel.

The page fault notifier does (almost) all that I need to trace exactly which piece of code inside X is causing the page faults. So, as I said here, I compare the notifier’s output with the symbol table of X binary disassembled. Believe me, it works!

So I spent a lot of time seeing which address is faulty, searching it on the X code and locking it on the memory. When the variable is global I move it to other ELF section called ‘input_data’. When the fault occurs on the text I move it to a ELF section called ‘input_code’. Then I lock this two sections on the phisycal memory using mlock(). Unfortunately the cursor still lags when the system is swaping to death (I used a simple memory hog to get this state). I’ll show you why.

As expected, the page fault notifier still accusing faults comming from the X process, but the address which these faults occur it’s not shown on the objdump’s output, leading me to not lock it (duhh) . Let me explain what I’m doing to test it.

I start the X with the brand new input thread, I run the memory hog and wait for some seconds until it consumes a lot of memory. So then I stop the hog and register the notifier. All the page fault now will be displayed on /var/log/messages. So I move the mouse — attention: this is the exacly moment where a non-locked X process will search for pages and, as the pages are not in memory, will generate a page fault –. When the input code (and datas) is locked it prints this and all the addresses that you see there doesn’t belong to what objdump shows. So what I should lock?! I don’t know… It shouldn’t prints anything if all the code/text were locked correctly (indeed, when I run the test using mlockall() it doesnt’t prints anything). Also, the same test but without locking anything shows this.

So on, I’m not seeing any differences on the cursor’s movement with or without mlock’ing (but yes when I use mlockall() and also when I use the input thread. Don’t make confusion!)