Date: Sun, 18 Jul 2010 16:21:01 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-sparc64@FreeBSD.org Subject: Re: [RFC] Event timers on sparc64/sun4v Message-ID: <20100718142101.GY4706@alchemy.franken.de> In-Reply-To: <4C42A5B9.7080901@FreeBSD.org> References: <4C404018.6040405@FreeBSD.org> <20100716213503.GT4706@alchemy.franken.de> <4C42A5B9.7080901@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100718142101.GY4706>