Re: mpsafe psm driver needed

On Jan 14, 2008, at 7:20 AM, John Baldwin wrote:
> On Monday 14 January 2008 06:00:54 am Philip Paeps wrote:
>> On 2008-01-13 21:25:03 (+0100), Kris Kennaway <kris_at_FreeBSD.org>  
>> wrote:
>>> I've been looking at some mutex profiling traces from users of 6.x  
>>> and 7.x
>>> who are reporting that their mouse pointer sometimes freezes when  
>>> their
>>> system is busy.  In most of the situations I have looked at this  
>>> is because
>>> the psm driver is Giant-locked, and competes with other things  
>>> like the
>>> syncer (in 6.x), or sysctl calls (I have a WIP for this that I  
>>> need to
>>> revisit).
>>>
>>> This is a minor problem from a grand architectural point of view  
>>> but an
>>> important one from a usability point of view.  I believe these  
>>> particular
>>> interactivity problems would be resolved if the psm driver no longer
>>> required Giant.  Is anyone able to work on this?
>>
>> I have taken a look at this in the past.  It's not a trivial problem.
>>
>> There is a lot of what I can only charitably call "legacy code" in  
>> psm and it
>> appears that as soon as you touch any of it, it upsets at least one  
>> brand of
>> KVM "out there".
>>
>> One of my mentees has been working on a rewrite for a while, but  
>> the project
>> has not yet been committed to cvs.
>>
>> jls: any news on this?
>
> Does psm(4) interface with any subsystems like tty(4)?

The problem is that it interfaces with syscons because of its  
interaction with the
atkbd hardware.  I looked at this as well a few years ago, and it's a  
huge mess to
detangle.  Syscons, while it works fairly well overall, it a big mess  
when it comes to
internal interfaces; code flows up and down the stack several times  
for a single
operation, so it makes it hard to lock in a sane and safe way.  I  
don't know what the
best answer is for it; if what Philip said about his associate is  
true, I'm impressed.
But beyond that, I don't know if it's best to try to do discrete but  
slow locking on
the existing architecture and deal with the inevitable deadlocks that  
will appear, or
if it's better to look at a different console architecture again.

Scott