From owner-freebsd-arch@FreeBSD.ORG Tue Jan 19 19:39:45 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 170DE10656A7; Tue, 19 Jan 2010 19:39:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8736C8FC23; Tue, 19 Jan 2010 19:39:44 +0000 (UTC) Received: from c220-239-227-214.carlnfd1.nsw.optusnet.com.au (c220-239-227-214.carlnfd1.nsw.optusnet.com.au [220.239.227.214]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0JJdfaS009144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 06:39:42 +1100 Date: Wed, 20 Jan 2010 06:39:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <201001191413.03682.jhb@freebsd.org> Message-ID: <20100120062222.N68139@delplex.bde.org> References: <3bbf2fe10911271542h2b179874qa0d9a4a7224dcb2f@mail.gmail.com> <201001191144.23299.jhb@freebsd.org> <20100120042822.L4223@besplex.bde.org> <201001191413.03682.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , FreeBSD Arch , Ed Maste Subject: Re: [PATCH] Statclock aliasing by LAPIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 19:39:45 -0000 On Tue, 19 Jan 2010, John Baldwin wrote: > On Tuesday 19 January 2010 1:53:32 pm Bruce Evans wrote: >> On Tue, 19 Jan 2010, John Baldwin wrote: >>> My feeling, btw, is that the real solution is to not use a sampling clock for >>> per-process stats, but to just use the cycle counter and keep separate user, >>> system, and interrupt cycle counts (like the rux_runtime we have now). >> >> The total runtime info is already available (in rux_runtime). It is >> the main thing that we use to see that scheduling is broken :-) -- we >> see that the runtime is too large or small relative to %CPU. I think >> using this and never using ticks for scheduling would work OK. Schedulers >> shouldn't care about the difference between user and sys time. Something >> like this is also needed for tickless kernels. > > I mostly care about splitting up the timers to attempt to remove the need > for statclock() by making more stats event-driven rather than sampled (to > help with a tickless kernel). vm stats are inherently sampled at points not related to vm events, but could probably be sampled on other interrupts. > I also would like to simplify calcru() and > remove the weird hacks to satisfy monoticity (sp?). I don't know of any hacks in calcru(). Did someone break it? :-). Bruce