From owner-freebsd-bugs@FreeBSD.ORG Mon Apr 2 11:23:20 2012 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C58C106564A for ; Mon, 2 Apr 2012 11:23:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9607C8FC0A for ; Mon, 2 Apr 2012 11:23:19 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA23262; Mon, 02 Apr 2012 14:23:16 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4F798C24.60609@FreeBSD.org> Date: Mon, 02 Apr 2012 14:23:16 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Oliver Pinter References: <201204020920.q329KCgm044092@freefall.freebsd.org> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/166568: [sched_ule] intr stuck in WAIT state X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 11:23:20 -0000 on 02/04/2012 14:06 Oliver Pinter said the following: > You are right, this is independent from intr, while it is "always" in > WAIT, but the load average dependend on r233599. See the attached > graph. > > The datasets are generated in single user boot ( top -s 1 -S -d 200 -m > cpu ) , with/without r233599. Without the ule patch, the load > decreased normally, but with r233599 it's hold to 0.5. > , I am not sure what those graphs represent exactly (the legend is not informative). You may want to contact mav@ directly. Maybe this is just an accounting issue, maybe not. I personally do not pay much attention to the load value. CPU load is much more useful to me. -- Andriy Gapon