High load event idl.

Oliver Pinter oliver.pntr at gmail.com
Sun Apr 29 12:04:52 UTC 2012


Hi all!

Removing dummynet from kernel don't chanage anything, that is releated
to load average. The loadavg hold to 0.70 +/- 0.2. (single user : sh +
top)

On 4/29/12, Alexander Motin <mav at freebsd.org> wrote:
> 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
>


More information about the freebsd-stable mailing list