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 :)


[1], consider that the first time that I hacked the kernel code was this week. So if something sounds weird…


9 thoughts on “Page fault notifier

  1. 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. 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…

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

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s