Date: Sun, 29 Apr 2012 15:59:11 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Oliver Pinter <oliver.pntr@gmail.com> Cc: Davide Italiano <davide@freebsd.org>, Albert Shih <Albert.Shih@obspm.fr>, Luigi Rizzo <rizzo@iet.unipi.it>, freebsd-stable@freebsd.org, Ian Smith <smithi@nimnet.asn.au> Subject: Re: High load event idl. Message-ID: <4F9D3B1F.2030208@FreeBSD.org> In-Reply-To: <CAPjTQNGesMffKZupENy0YWjC8LToutCyHh9uGqd-XKTN24goew@mail.gmail.com> References: <20120427203013.GB60961@pcjas.obspm.fr> <CAPjTQNFsHZQLp8oMwhjkAWLnYZ5mPv9kr9=X5GhqHqExoHM0yw@mail.gmail.com> <20120427213459.GA61125@pcjas.obspm.fr> <4F9B946D.3030607@FreeBSD.org> <CAPjTQNGts290DyjORNfir8_rZ5S_vdog%2BJMEBA9mc2vJhUa=jg@mail.gmail.com> <4F9CCEF2.6050609@FreeBSD.org> <20120429155512.M91148@sola.nimnet.asn.au> <4F9CDE91.1060300@FreeBSD.org> <CAPjTQNF=0Hgq_7BxeK_8o6DRQ%2BUJ_r94Y3PqwF8f_ccDeA_hHQ@mail.gmail.com> <4F9D2F0C.4050501@FreeBSD.org> <CAPjTQNGesMffKZupENy0YWjC8LToutCyHh9uGqd-XKTN24goew@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/29/12 15:27, Oliver Pinter wrote: > http://oliverp.teteny.bme.hu/freebsd/ktr/ OK. Now there is no dummynet, but I've found there two more things: 1. for some reason some acpi_thremal thread seems to consume about 0.37s of time every 10s. I have no idea what is this. It's not 0.7 load, but still strange at least. 2. I suspect another possible synchronization between ehci driver and loadavg as result of interrupt sharing between HPET timer used for time events and EHCI USB hardware. Not sure what to do about this. Please send _verbose_ dmesg to check whether this interrupt sharing is unavoidable. > On 4/29/12, Alexander Motin<mav@freebsd.org> wrote: >> 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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F9D3B1F.2030208>