High load event idl.
Alexander Motin
mav at FreeBSD.org
Sun Apr 29 12:07:51 UTC 2012
On 04/29/12 15:04, Oliver Pinter wrote:
> 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)
New ktr dump?
> 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