Page fault notifier

This week I tried to lock in the physical memory the Xorg’s input code using mlock(). To do this I traced the code minutely and locked all the text and data related to input. I didn’t get success. The mouse still lags when the system is paging (you might remember that with mlockall() all worked wonderful *except* that it eats much memory). So what might be happening is that something is not locked yet. To guarantee it I searched for a user-space tool that traces page fault. I only found the ‘truss’ command on Solaris. Linux (my OS) doesn’t provide no one (‘strace’ don’t do this).

So I surrendered to the kernel space tools putting some ‘print’ in the kernel code (before I tried a little systemtap and kprobe without success). Then I made a kernel module [0] using the notifier scheme which already exists inside the kernel. The problem is that the page fault notifier doesn’t show the address which happened the fault. So I made a patch to increment this functionality [1].

Using ‘objdump -t -d Xorg’ shows all the symbols and addresses I want. Now I must compare the module’s output with the dump and be happy :)

[0] http://web.inf.ufpr.br/vignatti/code/page_fault_notifier.c

[1] http://lkml.org/lkml/2007/7/27/8, consider that the first time that I hacked the kernel code was this week. So if something sounds weird…

About these ads

9 Responses to “Page fault notifier”

  1. Rudd-O Says:

    I’m concerned that this work will mask general jerkiness in the Linux kernel which should probably be nuked at the source. Can this be used to help debug and *fix* the kernel instead?

    However, I find it commendable :-). Too many years of too little RAM in my computers. Too many erroneous mouse clicks as a set of consequences.

  2. Rudd-O Says:

    Oh and your layout for the comment form is a fantastic idea.

  3. vignatti Says:

    The layout? This is not my authority! :) As you see in the page’s footnote is from Bryan Veloso…

  4. martin Says:

    I think this can not work… As soon as code outside the input pathes runs the X server can touch any of it’s memory and will block waiting for page in. Locking only parts into ram needs some mechanism to make sure other code pathes are not touched… And i don’t think that can work in the X-Server… But maybe you can gain enough to make it work if really only the mouse code is used and all other X11 apps are blocked on page in themselfes…

  5. vignatti Says:

    Hi martin. I already did a PoC which locks the mouse’s footprint getting a smoother cursor. Please take a look at this thread: http://lists.freedesktop.org/archives/xorg/2007-July/026258.html

    thanks

  6. martin Says:

    Hi, vignatti. I didn’t think about mouse handling in an thread. That might be a good idea, to keep the mouse responsive.

  7. Phil Pishioneri Says:

    This might help: http://people.redhat.com/drepper/pagein.html

  8. vignatti Says:

    Hi Phil, Thanks for pointing this out, but I already tried it. Please see the 2nd-to-last paragraph of this post:
    http://vignatti.wordpress.com/2007/07/17/xorg-input-thread-summary-or-something-2/

  9. mlock()’ing adventure « Tiago Vignatti Says:

    [...] 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, [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: