svn commit: r195960 - in head/sys/dev/usb: . controller input

[M. Warner Losh]

In message: <200908030827.21108.hselasky at c2i.net>
            Hans Petter Selasky <hselasky at c2i.net> writes:
: On Sunday 02 August 2009 21:58:14 Robert N. M. Watson wrote:
: > On 2 Aug 2009, at 20:29, Alfred Perlstein wrote:
: > > * Robert Watson <rwatson at FreeBSD.org> [090801 15:15] wrote:
: > >> On Sat, 1 Aug 2009, Hans Petter Selasky wrote:
: > >>>>> This has slowed down core dumps very significantly.  What used
: > >>>>> to take
: > >>>>> 10-15s on my system now takes around 3 minutes.  A simple test
: > >>>>> is to
: > >>>>> break into ddb and "call doadump" with or without this rev.  I
: > >>>>> have a
: > >>>>> serial console on this machine and so I can use ddb whether the
: > >>>>> attached
: > >>>>> USB keyboard works or not.
: > >>>
: > >>> It's because there is a DELAY(1000) in the UKBD's polling routine
: > >>> so that
: > >>> key- repeating will work, no magic.
: > >>
: > >> Given a choice between dumping 10x faster and having automatic key
: > >> repeat
: > >> in DDB, I'd lean towards the former.  :-)
: > >
: > > Robert, and *@freebsd.org,
: > >
: > > Hans should be back in a day or so to address this.  If critical I can
: > > probably back out the offending code, but I think it makes sense to
: > > wait a few days more for a more comprehensive fix.
: >
: > That's my feeling too -- however, I think it would be useful to
: > generate a small concept test patch that disables the key repeat
: > behavior and see if it restores some/all performance. Scott's argument
: > suggests only some, but perhaps we'd get quite a bit, which is what
: > we're looking for. We wouldn't commit the patch but it would let us
: > know we're on the right track.
: 
: Hi,
: 
: I'm back. 
: 
: I see two solutions:
: 
: 1) Disable the timekeeping if no keys are pressed.
: 
: 2) Second option is to use getmicrotime. Actually what I need is just a 
: millisecond time reference so I know when to repeat the last key.
: 
: Any opinions? DELAY() or getmicrotime() ?

I'd note the state at each poll, and if > 1ms has passed since the
down event, I'd repeat.  I wouldn't use DELAY at all to see if you
needed to repeat: I'd let the clocking of the polling drive you here
(eg, you know that someone else will call it a lot, so leverage that
to avoid the delay).

Warner