From owner-freebsd-sparc64@FreeBSD.ORG Sun Jul 18 14:21:03 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 691CA106566B; Sun, 18 Jul 2010 14:21:03 +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 97D648FC13; Sun, 18 Jul 2010 14:21:02 +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 o6IEL1j5013665; Sun, 18 Jul 2010 16:21:01 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6IEL1gD013664; Sun, 18 Jul 2010 16:21:01 +0200 (CEST) (envelope-from marius) Date: Sun, 18 Jul 2010 16:21:01 +0200 From: Marius Strobl To: Alexander Motin Message-ID: <20100718142101.GY4706@alchemy.franken.de> References: <4C404018.6040405@FreeBSD.org> <20100716213503.GT4706@alchemy.franken.de> <4C42A5B9.7080901@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C42A5B9.7080901@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: Sun, 18 Jul 2010 14:21:03 -0000 On Sun, Jul 18, 2010 at 09:56:57AM +0300, Alexander Motin wrote: > Marius Strobl wrote: > > please don't commit this as-is: > > - using the stick instead of the tick counter for machines with CPUs > > and thus tick counters running at different speeds has turned out > > to be suboptimal, probably due to the fact that the 12.5MHz the > > stick counters typically are driven by don't provide sufficient > > granularity. Thus the more desireable variant for these machines > > probably is to provide the tick counter of the BSP as the only > > non-per-CPU timer and forward it to the APs via IPIs. This also > > leaves the stick counter of all >= US-III machines generally > > available for driving statclock, which likely is also desirable. > > - I'd like to keep the tick grace check as this caused problems in > > the past. Probably tick_et_start() just should return an error > > in this case. > > - I don't like wasting CPU cycles for determining whether the > > workaround for BlackBird CPUs is needed (assuming #1 above is > > implemented so distinguishing stick/tick is no longer needed) > > with every (s)tick interrupt which are a lot as this just won't > > ever change during runtime, i.e. I'd like to keep the different > > interrupt handlers which are set up as needed. > > - Replacing intr_disable_all() with intr_disable() on sun4v > > probably isn't a good idea as the latter doesn't disable IPIs > > as it does on sparc64 and other architectures. > > Here is new path, updated respecting two last points: > http://people.freebsd.org/~mav/timers_sparc2.patch Looks better, but can't you just implement the tick grace check in tick_et_start() and let it return an error if the interval is too short until there maybe is an MI way to supply a minimum period? Also please follow style(9) and don't initializing variables in the declarations and leave tick_{clear,start} at the end of the file in order to not move code around unnecessarily. > > Don't you have some spare system with stick problems, so I could play > with it? I have but I recently moved and am currently busy with semester finals so it'll probably be mid-August when I'm able to set it up again. I'm not sure I'll be able to provide remote access though. > And some documentation? I am curious, what is wrong there. :) Just look at the documentation of US-III or later CPUs: www.cs.pitt.edu/~cho/cs2410/currentsemester/handouts/USIIIv2.pdf Marius