From owner-freebsd-stable@FreeBSD.ORG Sun Apr 29 12:27:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7BC8106566B; Sun, 29 Apr 2012 12:27:33 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 363ED8FC08; Sun, 29 Apr 2012 12:27:33 +0000 (UTC) Received: by yenl9 with SMTP id l9so1219136yen.13 for ; Sun, 29 Apr 2012 05:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5mtaEt6WBvNVe4dyd5+O/x/L5d+FEEXggLoqN7NIZu0=; b=H2qOKQq35xGfEPGl6NFKbC31NbP8zJ1Mats3ByVf5i0hCiiuDmMbe7CeU97/k0ynHT zfXlGeqerB6vuSDMlsKWx4hlq+ZHJJKmEGFX42xDUduZG1zvKaK0uJ2EZPrj8m6C5NgK tb9ZwJiW++tBB/VD3dU/AQm24GSmH8B/ltrsT4XGwv9dDGSkpEmEkgXJjKTCMy7MJRmL Lxp/W7b5ffbgbhgbWgyxVOO4mIF9orrNaSICTVo/WpNKviEqgneZJ4kEUa2kIfg6CzEX Ui5sRlZuWfvBuq9Xp9sWxVTDOzKQThzkeyqkWaHPZQC+kT8ykkHtE1uJ2uGzSRvphTXV 7/qQ== MIME-Version: 1.0 Received: by 10.236.192.136 with SMTP id i8mr11752804yhn.122.1335702452221; Sun, 29 Apr 2012 05:27:32 -0700 (PDT) Received: by 10.236.161.97 with HTTP; Sun, 29 Apr 2012 05:27:32 -0700 (PDT) In-Reply-To: <4F9D2F0C.4050501@FreeBSD.org> References: <20120427203013.GB60961@pcjas.obspm.fr> <20120427213459.GA61125@pcjas.obspm.fr> <4F9B946D.3030607@FreeBSD.org> <4F9CCEF2.6050609@FreeBSD.org> <20120429155512.M91148@sola.nimnet.asn.au> <4F9CDE91.1060300@FreeBSD.org> <4F9D2F0C.4050501@FreeBSD.org> Date: Sun, 29 Apr 2012 14:27:32 +0200 Message-ID: From: Oliver Pinter To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: Davide Italiano , Albert Shih , Luigi Rizzo , freebsd-stable@freebsd.org, Ian Smith Subject: Re: High load event idl. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 12:27:33 -0000 http://oliverp.teteny.bme.hu/freebsd/ktr/ On 4/29/12, Alexander Motin 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 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 >