From owner-freebsd-sparc64@FreeBSD.ORG Wed Jul 28 20:09:30 2010 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CEED1065675; Wed, 28 Jul 2010 20:09:30 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id E78858FC0A; Wed, 28 Jul 2010 20:09:29 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o6SK9Ssm011716; Wed, 28 Jul 2010 22:09:28 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6SK9SGl011715; Wed, 28 Jul 2010 22:09:28 +0200 (CEST) (envelope-from marius) Date: Wed, 28 Jul 2010 22:09:28 +0200 From: Marius Strobl To: Alexander Motin Message-ID: <20100728200928.GC75632@alchemy.franken.de> References: <4C404018.6040405@FreeBSD.org> <20100716213503.GT4706@alchemy.franken.de> <4C42A5B9.7080901@FreeBSD.org> <20100718142101.GY4706@alchemy.franken.de> <4C433391.4080808@FreeBSD.org> <20100719122423.GA4706@alchemy.franken.de> <4C44694C.9040108@FreeBSD.org> <4C46E3BB.7060204@FreeBSD.org> <20100728070919.GB75632@alchemy.franken.de> <4C4FDBB2.5000503@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C4FDBB2.5000503@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@FreeBSD.org Subject: Re: [RFC] Event timers on sparc64/sun4v X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 20:09:30 -0000 On Wed, Jul 28, 2010 at 10:26:42AM +0300, Alexander Motin wrote: > Marius Strobl wrote: > > On Wed, Jul 21, 2010 at 03:10:35PM +0300, Alexander Motin wrote: > >> Here is updated patch for latest HEAD, which should handle this: > >> http://people.freebsd.org/~mav/timers_sparc4.patch > >> > >> I also added support for STICK timecounter. For this moment with lowest > >> priority to not use it by default, until it is tested. > > > > The patch looks ok and seems to work as expected on MP US-IIIi. > > However, I'd suggest to just use TICK_QUALITY_{M,U}P for the > > quality of the STICK timecounter but negated for now; I see no > > reason why the STICK timecounter should be of any other quality > > (from the hardware point of view) than the TICK one and whatever > > the solution is to make the TICK timecounter work with locks etc > > also needs to be applied to the STICK one (maybe on some machines > > the synchronicity across CPUs actually happens to be sufficient > > but I'd like to rather not make any assumptions about machines > > that f.e. group CPUs by coherency domain etc). > > As you said before, STICK has lower resolution then TICK (though not so > much), so I would set it's quality a bit lower. Correct, depending on model it's driven by a frequency between 5 and 20MHz. However, as far as the MI part of the timecounter code is concerned quality and frequency, i.e. resolution, are orthogonal. If two timecounters have the same quality but are driven by different frequencies the timecounter with the better resolution is preferred, i.e. the resolution shouldn't be reflected by the quality parameter. > And it has more chances > to work synchronously then TICK on MP, so I would set it's quality > higher there. I don't actually see the reason for using negative > qualities, unless timers are really broken. In such case if there will > be no other timers, system will fall back to the dummy, which I have > doubts is better then anything else. I don't see a practical difference between TICK and STICK based timecounters in the MP case as far as synchronicity is concerened; the latter might have (well, in case the CPUs are running at different speeds it actually has) a better synchronicity but we just can't assume this and in order to provide a stable timecounter we need to bind reading the (S)TICK count to a CPU anyway, in which case both have the same quality. The reason I suggest a negative qualitiy is that your patch is missing binding reading the STICK count to CPU, i.e. is broken in the MP case. I wouldn't worry about binding this to the BSP too much, even if this means that further down the road this has negative impact on running a tickless kernel as this only affects some low-cost (or at least what low-cost is to Sun) models which have no alternative to using the (S)TICK timecounter (there is some price to pay after all ...). Marius