From owner-freebsd-stable@FreeBSD.ORG Sun Apr 29 06:24:28 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 5BB8D1065670; Sun, 29 Apr 2012 06:24:28 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 9A5778FC14; Sun, 29 Apr 2012 06:24:27 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so1469000wib.13 for ; Sat, 28 Apr 2012 23:24:20 -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=hHwL3Euf1q8ZF7eMq4bdIP+6fcsns/N324P0yj7/9Ss=; b=AgG1xzghm0DBVs5FweRraf22uaf3+77UMiaoaH1T5JNQlRBx0uiZQNYc4Q0a4rl9XF PX6lHxTJScBoXyXfSrF5Gc1aJQsThezqtedImXBKXrsmyLu3vSN8nuHv7eqwCKs/BFKs w5gGL+jJshBJzi0O/K42VfFJBIOCAvovcV+cu0R4PwpTLvcdmH0XRdbCdJR5U+zJ0gAt EZUud1MZ0IN4vvZAEqkkQOh9YpWUONiUPDrbljpomTlKndDXkBnbSUUvFpcKb0y8zTq5 7/VgQKTdvXeEeavlk4Z8lycNz/9XuBXcT7CUoI7OxIlWlM6Or9cAMeg9gxsddSLbh9lp DSNA== Received: by 10.180.94.33 with SMTP id cz1mr19458466wib.13.1335680660514; Sat, 28 Apr 2012 23:24:20 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id h8sm29140935wix.4.2012.04.28.23.24.18 (version=SSLv3 cipher=OTHER); Sat, 28 Apr 2012 23:24:19 -0700 (PDT) Sender: Alexander Motin Message-ID: <4F9CDE91.1060300@FreeBSD.org> Date: Sun, 29 Apr 2012 09:24:17 +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: Ian Smith 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> In-Reply-To: <20120429155512.M91148@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Albert Shih , freebsd-stable@freebsd.org, Luigi Rizzo , Oliver Pinter 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 06:24:28 -0000 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