From owner-freebsd-stable@FreeBSD.ORG Sun Apr 29 12:07:51 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 A344D1065688; Sun, 29 Apr 2012 12:07:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EC14A8FC19; Sun, 29 Apr 2012 12:07:50 +0000 (UTC) Received: by bkvi17 with SMTP id i17so792053bkv.13 for ; Sun, 29 Apr 2012 05:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GOxwLZUSTICV9qJW/4WburFWBBmC8d6uHuLdNrxLNJw=; b=bdecdAYhtLGwLNm62AZzAMxXZSuF8S/cndaUF9fhpp4VMtVYEatyBZpa9inDxkl6yD Wx3eGPkMS8bkNad0R0cuvZeOoJtCjZTJ2QZk6YuvgOY9rselJulzEAO/m+WCG981B8ry O9EX2jwQydVjyDRLOaVQ5Dksj4Y8gyN4mL4HZ4gB4zhT3tUfzJjwCffNaGpTlGMT7qxX nI11NThoEUFV6cH7LOJWEWaR2qZOk2UF/gqI8hFt7P6VAYTaK5UL+7HuRm1MjQyA+Q9S 0XxObe5TRjjaDcYTW/bdkxhO+l0O+Io7Db8aev/KfbnycunjkSrfz1Ms5r9tWz5VhH/r KYdg== Received: by 10.204.154.209 with SMTP id p17mr6182714bkw.6.1335701264396; Sun, 29 Apr 2012 05:07:44 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id zx16sm21195081bkb.13.2012.04.29.05.07.42 (version=SSLv3 cipher=OTHER); Sun, 29 Apr 2012 05:07:43 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F9D2F0C.4050501@FreeBSD.org> Date: Sun, 29 Apr 2012 15:07:40 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120328 Thunderbird/10.0.3 MIME-Version: 1.0 To: Oliver Pinter 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:07:51 -0000 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