mouse interactivity (Re: svn commit: r182109
kris at FreeBSD.org
Tue Aug 26 13:20:39 UTC 2008
Marius Nünnerich wrote:
> On Mon, Aug 25, 2008 at 4:19 PM, Ed Schouten <ed at 80386.nl> wrote:
>> * Kris Kennaway <kris at FreeBSD.org> wrote:
>>> Ed Schouten wrote:
>>>> Author: ed
>>>> Date: Sun Aug 24 15:20:44 2008
>>>> New Revision: 182109
>>>> URL: http://svn.freebsd.org/changeset/base/182109
>>>> Make sysmouse(4) use its own locks, instead of using Giant.
>>>> When I changed syscons(4) to work with the MPSAFE TTY code, I just
>>>> locked all device nodes down using the compatibility feature that allows
>>>> you to override the TTY's lock (Giant in this case). Upon closer
>>>> inspection, it seems sysmouse(4) only has two internal variables that
>>>> need locking: mouse_level and mouse_status.
>>>> I haven't done any performance benchmarks on this, though I think
>>>> won't have any dramatic improvements on the system. It is good to get
>>>> rid of Giant here, because the third argument of tty_alloc() has only
>>>> been added to ease migration to MPSAFE TTY. It should not be used when
>>>> not needed.
>>>> While there, remove SC_MOUSE, which is a leftover from the MPSAFE
>>> This might help mouse interactivity for desktop users that have legacy
>>> Giant-locked systems in use (e.g. busy MSDOS filesystems, giant-locked
>>> disk drivers), etc.
>> Yes, but only a very very little bit. moused still delivers the input to
>> /dev/consolectl, which is still Giant locked. The part where the Xorg
>> server reads from /dev/sysmouse is now Giant-free.
> Are you going to lock that one too? I have some problems with a sluggish PS/2
> now that I can use nvidia(4) again without crashing).
Unless you fit into a situation like the one I described, it doesn't
sound like the giant locking is the problem for you. You can check by
enabling lock profiling.
More information about the freebsd-current