High load event idl.

[Alexander Motin]

On 04/29/12 09:09, Ian Smith wrote:
> On Sun, 29 Apr 2012 08:17:38 +0300, Alexander Motin wrote:
>   >  On 04/29/12 01:53, Oliver Pinter wrote:
>   >  >  Attached the ktr file. This is on core2duo P9400 cpu (
>   >  >  smbios.system.product="HP ProBook 5310m (WD792EA#ABU)" ). The workload
>   >  >  is only a single user boost: sh + top running, but the load average is
>   >  >  near 0.5.
>   >
>   >  ktr shows no real load there. But it shows that you are using dummynet, that
>   >  schedules its runs on every hardclock tick. I believe that load you see is
>   >  the result or synchronization between dummynet calls and loadvg sampling,
>   >  both of which called from hardclock. I think removing dummynet from equation,
>   >  should hide this problem and also reduce you laptops power consumption.
>   >
>   >  What's about fixing this, it is loadavg sampling algorithm that should be
>   >  changed. Fixing dummynet to not run on every hardclock tick would also be
>   >  great.
>
> Wading in out of my depth, and copying Luigi in case he misses it .. but
> even back in the olden days when HZ defaulted to 100, one was advised to
> use HZ>= 1000 for smooth dummynet traffic shaping dispatch scheduling.
>
> I wonder, with the newer clocks and timers, whether there is another
> clock that could be used for dummynet scheduling, that would not have
> this effect (even if largely cosmetic?) on load average calculation?

First of all, the easiest solution would be to make dummynet to schedule 
callout not automatically, but on first queued packet. I believe that in 
case of laptop the queue should be empty most of time and the callout 
calls are completely useless there. Luigi promised to look on this once.

What's about better precision/removing synchronization -- there is 
starting GSoC project now (by davide@) to rewrite callout(9) subsystem 
to use better precision allowed by new timer drivers. While now it is 
possible to get raw access to additional timer hardware available on 
some systems, I don't think it is a good idea.

-- 
Alexander Motin