From owner-cvs-src@FreeBSD.ORG Tue Sep 5 18:18:26 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC8E716A4DD; Tue, 5 Sep 2006 18:18:26 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1802643D4C; Tue, 5 Sep 2006 18:18:25 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.49] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.6/8.13.6) with ESMTP id k85IIMxK031025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Sep 2006 11:18:24 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <44FDBF5F.3010107@FreeBSD.org> Date: Tue, 05 Sep 2006 11:18:07 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Baldwin References: <200609051715.k85HFPtF078969@repoman.freebsd.org> <200609051327.50788.jhb@freebsd.org> In-Reply-To: <200609051327.50788.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 local_apic.c src/sys/amd64/amd64 local_apic.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2006 18:18:27 -0000 John Baldwin wrote: > On Tuesday 05 September 2006 13:15, Maxim Sobolev wrote: >> sobomax 2006-09-05 17:15:25 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/i386/i386 local_apic.c >> sys/amd64/amd64 local_apic.c >> Log: >> The FreeBSD by default "disables" hyper-threading cores, by not scheduling >> any threads to them. However, it still counts those cores as "active but >> permanently idle" when calculating system-wide CPUs statistics. It is >> incorrect, since it skews statistics quite a bit and creates real problems >> for certain types of applications (monitoring applications for example), >> by making them believe that the system does have enough idle CPU > resources, >> while in fact it does not. >> >> Correct the problem by not calling performance counting routines > on "disabled" >> cores. The cleaner solution would be to just disable APIC timer interrupts > on >> those cores completely, but ENOTIME here and it is not clear if the >> additional complexity really worth minor performance gain. > > Is this going to break various places dividing stats by hw.ncpu (in userland) > or mp_ncpus (in kernel)? Well, I don't think so, since all those statistics tells is how many times system is found in particular state (idle, system, userland, interrupt), it doesn't tell how exactly those states are distributed across available CPUs, so that dividing it by number of CPUs doesn't change the whole picture - you can only say that each CPU say is loaded by XX% when the whole system is loaded by XX%. Therefore, I can't imagine any situation when this change would create a problem. > (That is, are there any such places. If so, you > just broke them.) No, I believe that I did not, unless you can provide example of the contrary. -Maxim