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<m...@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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
