From owner-freebsd-stable@FreeBSD.ORG Tue Aug 14 20:58:41 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 DCF09106564A for ; Tue, 14 Aug 2012 20:58:41 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 536D58FC12 for ; Tue, 14 Aug 2012 20:58:40 +0000 (UTC) Received: by lbbgk8 with SMTP id gk8so618615lbb.13 for ; Tue, 14 Aug 2012 13:58:39 -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=4VGpOHrI7ITerbAV5W1cpDMcm1Ugu6S7nHPnbfFWBVc=; b=VYiB6nlugNdY0dIYSa17NkcwhI8MlOO7yBBO3GNHClUM5Uv/7Kc9utAEKEEmV1ah/+ vBFB9pBrIcWLPsKe6cW8t3a41X6JRiypH9CgnkeelsoNIS64WYurmfcBMoWxEuenWa3T VTbqMMAbxQXRLJDTvFHMkvzq1p/rWIlfxF0MxnGAQST4lJtEcy6MX+yS2FGw1xWE9p6q 7zd940fSk2A2wiN+CPOSFtIx1eHfm/p39nvjwNK7RDU3kjHAXLgdg+56mzzX68wXQ5u6 Xbu9xP0QCSWjnOTOVrViSMjviPs1WBQAvPuJc0H1tgntWAgrjKOPHEFgrkhwEORqnfzo 9Sjw== Received: by 10.112.102.68 with SMTP id fm4mr3631450lbb.19.1344977919814; Tue, 14 Aug 2012 13:58:39 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (213-227-240-37.static.vega-ua.net. [213.227.240.37]) by mx.google.com with ESMTPS id nf5sm3299980lab.3.2012.08.14.13.58.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 13:58:38 -0700 (PDT) Sender: Alexander Motin Message-ID: <502ABBFC.9090602@FreeBSD.org> Date: Tue, 14 Aug 2012 23:58:36 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Adam McDougall References: <4F9CCEF2.6050609@FreeBSD.org> <20120429155512.M91148@sola.nimnet.asn.au> <4F9CDE91.1060300@FreeBSD.org> <4F9D2F0C.4050501@FreeBSD.org> <20120429122714.GA56829@ravenloft.kiev.ua> <4F9D3DF8.9000800@FreeBSD.org> <20120429133056.GA58422@ravenloft.kiev.ua> <4F9D4491.2060007@FreeBSD.org> <20120814192540.GV68639@egr.msu.edu> In-Reply-To: <20120814192540.GV68639@egr.msu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org 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: Tue, 14 Aug 2012 20:58:41 -0000 On 14.08.2012 22:25, Adam McDougall wrote: > On Sun, Apr 29, 2012 at 04:39:29PM +0300, Alexander Motin wrote: > > On 04/29/12 16:30, Alex Kozlov wrote: > > On Sun, Apr 29, 2012 at 04:11:20PM +0300, Alexander Motin wrote: > >> On 04/29/12 15:27, Alex Kozlov wrote: > >>> On Sun, Apr 29, 2012 at 03:07:40PM +0300, 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? > >>> I have similar issue on one of my laptops. Should I provide ktr dump? > >>> http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027133.html > >> In your case HPET also shares interrupt with other devices. I suspect > >> that may be a reason. Every time when swi thread runs loadavg, other CPU > >> runs shared interrupt handler, that is accounted as result. Please show > >> your verbose dmesg. > > Attached. > > In your case HPET could solely use IRQ22 that seems free now. After > recent changes in ACPI code it is detected before PCI devices and so > doesn't avoids sharing. You may try to hint it specific IRQ by adding to > loader,conf line: > hint.hpet.0.allowed_irqs="0x00400000" > > -- > Alexander Motin > > I think I am having the same issue on my Sun Fire x4150 servers. It > goes away when I sysctl kern.eventtimer.timer=LAPIC but I'm hesitant to > use local workarounds in case they become pessimistic in the future. > I'm not sure all of my systems would have the same free irqs (including > after potential addition of expansion cards) so it might be a pain to > determine an appropriate allowed_irqs setting for each. I tried > hint.hpet.0.allowed_irqs="0x00000000" for the sake of experiment and > that just results in LAPIC being used since HPET is removed from > kern.eventtimer.choice. I've attached a verbose dmesg (will probably be > stripped from the list, hence the Cc:). > > Is there a limit to how high the irq can be set or could I perhaps set > it high enough that it is unlikely to conflict with other hardware? Is > there a chance we can find an automatic fix for this issue, or should I > just stick with LAPIC at the expense of whatever the HPET event timer > gets me? Or something else? I feel the partially random load average > level makes it difficult to measure a low load and can be misleading > during problem debugging. Thanks. HPET theoretically can use any IRQ from 0 to 31. Practically there could be different limitations. It is BIOS duty to tell us which IRQs are allowed to use. In your case IRQs 20-23 are allowed. Unluckily now system just gives to the HPET driver the first from the range. Problem with LAPIC timer is that it stops working when CPU goes to C3 or deeper idle state. These states are not enabled by default, so unless you enabled them explicitly, it is safe to use LAPIC. In any case present 9-STABLE system should prevent you from using unsafe C-state if LAPIC timer is used. From all other perspectives LAPIC is preferable, as it is faster and easier to operate then HPET. Latest CPUs fixed the LAPIC timer problem, so I don't think that switching to it will be pessimistic in foreseeable future. -- Alexander Motin