Re: mouse jumps with tcp_usrreq_wrapper

[Chuck Silvers <chuq%chuq.com@localhost>]

hi christoph,

contention on kernel_lock is plausible as a cause of mouse jumps.
the 7 ms of spinning that you show below isn't a lot of time though,
I'd be surprised if that was enough to cause a noticable hiccup.

I tried to reproduce this by moving the cursor around while
sending network traffic to the box with ttcp (ie. keeping the network
as busy as possible), but I didn't notice any problems.
maybe my test box is too fast.

if you want to pursue the kernel_lock contention theory,
you can try editing the generated VOP_POLL() function
to hardware "mpsafe = true".  the only vop_poll implementation
that does anything that needs locking is spec_poll(), and that
only in the VCHR case, and cdev_poll() will take kernel_lock itself,
so the caller doesn't need to do it too.  that should move the
contention from VOP_POLL() to cdev_poll(), and then you can add
a printf or something to find out which device or devices are being
used there, and then we can see how close those drivers are to being
mpsafe.  most likely it's the keyboard and/or mouse drivers, which
would need a bunch of work since the tty code isn't even close to mpsafe,
but at least this would confirm what's causing the mouse jumps.

-Chuck


On Mon, Apr 30, 2012 at 11:39:34AM +0200, Christoph Egger wrote:
> Hi Chuck,
> 
> thanks for fixing the mouse jumps with disk io (PR 46325).
> I still can reproduce mouse jumps with network io.
> 
> The way I can reproduce:
> 
> Use NetBSD/amd64 as desktop machine and ssh to
> a remote machine. Do something that keeps the
> local xterm busy (e.g. run a build on the remote
> machine).
> 
> A second way I can reproduce is to have $HOME
> mounted via nfs and run thunderbird. Fetch mails
> and tell thunderbird to store it somewhere under $HOME/.
> 
> I run 'lockstat cat' several times and whenever I
> reproduced a mouse jump I got this:
> 
> 
> -- Kernel lock spin
> 
> Total%  Count   Time/ms          Lock                       Caller
> ------ ------- --------- ----------------------
> ------------------------------
> 100.00     355      7.53 kernel_lock            <all>
>  68.49      39      5.16 kernel_lock            VOP_POLL+40
>  22.36     174      1.68 kernel_lock            cdev_poll+4d
>   3.87      53      0.29 kernel_lock            VOP_UNLOCK+40
>   1.51      12      0.11 kernel_lock            intr_biglock_wrapper+16
>   1.28      48      0.10 kernel_lock            tcp_usrreq_wrapper+2d
>   1.11      11      0.08 kernel_lock            VOP_READ+48
>   0.63      11      0.05 kernel_lock            VOP_LOCK+43
>   0.31       1      0.02 kernel_lock            cdev_read+4d
>   0.27       2      0.02 kernel_lock            VOP_WRITE+48
>   0.09       2      0.01 kernel_lock            softint_dispatch+161
>   0.06       1      0.00 kernel_lock            ipintr+41
>   0.01       1      0.00 kernel_lock            ip_slowtimo+1a
> 
> 
> Also 'top -u' shows that the Xorg process eats most cpu time
> and interrupt load is about 2.0% on cpu0 when the mouse jump happens.
> 
> My theory is that the mouse jump happens everytime when the
> Xorg process is blocked by the big kernel lock used with
> tcp_usrreq_wrapper().
> 
> Christoph