Re: A few questions and issues with dynticks, NOHZ and powertop
From: Dmitry Torokhov
Date: Mon Apr 05 2010 - 16:52:34 EST
On Mon, Apr 05, 2010 at 10:41:43PM +0200, Dominik Brodowski wrote:
> On Sun, Apr 04, 2010 at 08:42:43PM -0700, Arjan van de Ven wrote:
> > On 4/4/2010 3:47, Dominik Brodowski wrote:
> > >Hey,
> > >
> > >On Sat, Apr 03, 2010 at 04:53:26PM -0700, Dmitry Torokhov wrote:
> > >>On Sun, Apr 04, 2010 at 12:33:28AM +0200, Dominik Brodowski wrote:
> > >>>
> > >>>4) SynPS/2 touchpad:
> > >>>Why does moving the touchpad lead to sooo many IRQs? I can't look as fast
> > >>>as the mouse pointer seems to get new data:
> > >>> 62,5% (473,1)<interrupt> : PS/2 keyboard/mouse/touchpad
> > >>>
> > >>
> > >>80 pps @ 6 bytes/packet = 480 interrupts/sec.
> > >>
> > >>You can try using psmouse.rate=40 to limit it to 40 pps which should
> > >>bring it to the rate of standard PS/2 mouse at the expense of
> > >>sensitivity...
> > >
> > >as a sidenote: if we know -- like here -- that the next IRQ will be issued
> > >soon, in approximately 1.75 ms (well, at least on my system), might it make
> > >sense to make tick_nohz_get_sleep_length() smarter to know about this?
> > yes and no.
> > if you are very sure (95%+ or so) then absolutely it needs to know about this
> > so that the C state selection code can make a better decision.
> > Right now it tries to look at history to guess this delay.
> > Unfortunately we do not currently have such a concept in the code to make this
> > work... but it'd be really nice to have.
> Dmitry, are we "very sure" in this touchpad case?
Psmouse driver tries to not rely on any timing data really... But yes,
we do expect the next interrupt to arrive "shortly" and I guess the
driver could do some data gathering to collect average time between
interrupts. The question is - is it worth it?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/