[PATCH] hvc_console polling mode timer backoff

[Michael Ellerman]

On Thu, 2007-04-12 at 14:09 -0500, Olof Johansson wrote:
> On Thu, Apr 12, 2007 at 01:43:30PM -0500, Will Schmidt wrote:
> > On Thu, 2007-12-04 at 12:33 -0500, Linas Vepstas wrote:
> > > On Thu, Apr 12, 2007 at 11:14:36AM -0500, Will Schmidt wrote:
> > > > +/*
> > > > + * timeout will vary between the MIN and MAX values defined here.  By default
> > > > + * and during console activity we will use a default MIN_TIMEOUT of 10.  When
> > > > + * the console is idle, we increase the timeout value on each pass through
> > > > + * msleep until we reach the max.  This may be noticeable as a brief (average
> > > > + * one second) delay on the console before the console responds to input when
> > > > + * there has been no input for some time.
> > > > + */
> > > > +#define MIN_TIMEOUT		(10)
> > > > +#define MAX_TIMEOUT		(2000)
> > > 
> > > [...]
> > > > +				msleep_interruptible(timeout);
> > > 
> > > 
> > > These values are milliseconds (that's what the m in msleep stands for
> > > or at least it did last time I looked). This 10 is 1/100 of a second,
> > > which makes a responsive keyboard for even a very very fast typist.
> > > That's fine.  But 2000 is two seconds, which is longer than the amount 
> > > of time that I wait before I start panicking that something is broken. 
> > 
> > Well, I usually give my systems at least ten seconds before I start to
> > worry. :-) 
> > 
> > I did ponder the max value to use.   Though when I sit down at &random&
> > console in the lab, It often takes a moment for the terminal to warm up,
> > or for the screen to unblank.   With that in mind, a couple seconds max
> > for the console does not seem unreasonable to me.
> > 
> > Will see if other folks have an opinion either way.. 

I found the 2 second value was fine. If you're really paying attention
you might notice the lag, but if you're not expecting it I don't think
it's enough to really scare you.

> I wasn't going to bring it up since I think it's a good approach as is,
> but another thing that could be worth considering is to not just go
> from whatever value to min on every actual input, instead go down in
> delay a bit (say half the delay). Likewise you might be able to back off
> more aggressively than just one millisecond per iteration.   Of course,
> both of these should take min/max values into consideration.

I experimented with increasing the delay faster (100ms per iteration)
and found it effected the feel of the console too much when you're
actually typing. Though perhaps increasing by 10%-20% of the current
delay every iteration might work OK.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070413/7b314999/attachment.pgp>