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