From owner-cvs-all@FreeBSD.ORG Tue Sep 5 20:03:28 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D5FC16A4E0; Tue, 5 Sep 2006 20:03:28 +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 4F8C243D8F; Tue, 5 Sep 2006 20:03:03 +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 k85K2x90033671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Sep 2006 13:03:01 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <44FDD7E5.1000803@FreeBSD.org> Date: Tue, 05 Sep 2006 13:02:45 -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> <44FDBF5F.3010107@FreeBSD.org> <200609051435.37443.jhb@freebsd.org> In-Reply-To: <200609051435.37443.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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2006 20:03:28 -0000 John Baldwin wrote: >>> (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. > > linprocfs, but it lies anyway. I've engaged in hacks like this in 4.x, That's what I mean - I can't imagine how can you get any useful statistics out of CPU times by combining it with number of processors. > but I think they are just that: hacks. I think a real fix is to support > turning off CPUs in the MI code and allow userland to query via a non-hackish > interface how many CPUs are actually enabled and get appropriate load stats, > etc. based on that. Yes, that's would be nice. But in the meantime my goal is to resolve obvious regression we have in the 6.x release in the presence of the HTT CPU. -Maxim