From owner-freebsd-questions@FreeBSD.ORG Tue Aug 9 00:30:42 2011 Return-Path: Delivered-To: freebsd-questions@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55BA1106564A for ; Tue, 9 Aug 2011 00:30:42 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 2F69E8FC08 for ; Tue, 9 Aug 2011 00:30:41 +0000 (UTC) Received: by pzk33 with SMTP id 33so2891926pzk.18 for ; Mon, 08 Aug 2011 17:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=PZJmGo65pI5PQ7fMRWCmjl/0dMxpoKYofJJ9vR64Ifo=; b=B+NkdUDQH+ZZrfxj+fqRuYTg0wP+gthJpS/UZMVlIFJcRZH1QzyXIFGIVvroB/wkgw XWb4gfv/hsVJKbYJLLF1A31doyt5+MSNqTVSbt0pbonospN9QZEMUZM0PfKLRkagrA0B AHDbZb9rhP4LC1hC3oBieVnmKvJIETT8c1zOc= MIME-Version: 1.0 Received: by 10.142.48.20 with SMTP id v20mr6530608wfv.115.1312849841525; Mon, 08 Aug 2011 17:30:41 -0700 (PDT) Received: by 10.68.43.133 with HTTP; Mon, 8 Aug 2011 17:30:41 -0700 (PDT) In-Reply-To: <201108072028.09658.lobo@bsd.com.br> References: <201108072028.09658.lobo@bsd.com.br> Date: Mon, 8 Aug 2011 20:30:41 -0400 Message-ID: From: "b. f." To: Mario Lobo , freebsd-questions@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: High interrupt rate X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 00:30:42 -0000 On 8/7/11, Mario Lobo wrote: > On Sunday 07 August 2011 18:34:27 b. f. wrote: >> > I know 75% idle is not bad but this machine, when not under load on a >> > saturday night like today, used to be at around 98% idle 99% of the >> > time. Now its is at 72% idle 99.9% of the time. It has been like this >> > all day. >> > >> > The only things with a high interrupt rate are >> > >> > cpu0: timer 46922025 2000 >> > cpu1: timer 46918117 1999 >> > >> > What could be causing this? >> >> I don't know that 2 timer interrupts per-cpu, per kern.hz, is >> altogether unexpected for some configurations, under some conditions. >> What happens if you boot with kern.hz="100" in /boot/loader.conf, or >> set via the loader command line? What happens if you remove the >> DEVICE_POLLING option from your kernel (and _not_ just disable polling >> per-device)? What is the output from "sysctl kern.timecounter >> kern.eventtimer"? >> >> b. > > Thanks b. ! > > [~]>sysctl kern.timecounter > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC(-100) ACPI-safe(850) i8254(0) dummy(-1000000) > kern.timecounter.hardware: ACPI-safe > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.i8254.counter: 39201 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.ACPI-safe.mask: 16777215 > > > kern.timecounter.tc.ACPI-safe.counter: 1055460 > > > kern.timecounter.tc.ACPI-safe.frequency: 3579545 > > > kern.timecounter.tc.ACPI-safe.quality: 850 > > > kern.timecounter.tc.TSC.mask: 4294967295 > > > kern.timecounter.tc.TSC.counter: 1200011080 > > > kern.timecounter.tc.TSC.frequency: 1995401152 > > > kern.timecounter.tc.TSC.quality: -100 > > > kern.timecounter.smp_tsc: 0 > > > kern.timecounter.invariant_tsc: 1 > > [~]>sysctl kern.hz > kern.hz: 1000 > > [~]>sysctl kern.eventtimer > sysctl: unknown oid 'kern.eventtimer' > > I'll wait for your views on those before disabling polling on the kernel and > hz=100. It looks like your interrupt rate, while probably higher than needed, is not unexpectedly high for your configuration. But you can lower it if you want to do so. You are using a system before the introduction of the new eventtimer code. If you use 9.x, that has the new code and some other timer-related improvements, and you are not performing polling, then you can achieve a large reduction in the number of timer interrupts when the system isn't busy. You can still achieve a reduction on 8.x, but the reduction usually won't be as large as on 9.x under similar conditions. To reduce timer interrupts on an idle system running 8.x or 9.x, if you do not need to poll (most systems do not), remove DEVICE_POLLING from your kernel, and lower kern.hz to a suitable value -- 100 or 250, for example. For many workloads, a lower value is not only adequate, but may also be better in some ways. Also, you may want to consider using your TSC as the system timecounter, because it is usually more efficient to do so. This may not work for SMP, because if there are multiple TSCs on your system, they may not be synchronized. In 9.x, there is a test for synchronization, and the TSCs are preferred to the ACPI-safe timer if they satisfy this test and meet some other requirements. In 8.x, the user has to tell the system that it is safe to use the TSCs by adding: kern.timecounter.smp_tsc="1" to /boot/loader.conf. If you are not putting your cores into the C3 state, then you could try setting this via the loader command line, booting, and then seeing if the kern.timecounter.tc.TSC.quality is positive, kern.timecounter.hardware is TSC, and everything is working as expected. If the results are satisfactory, then you could add the above entry to /boot/loader.conf. But it would be better to do this on 9.x, where there are some added safeguards. b.