From owner-freebsd-arch@freebsd.org Sat Sep 3 06:42:11 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86E12BCD6AA for ; Sat, 3 Sep 2016 06:42:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 0FE3FC48; Sat, 3 Sep 2016 06:42:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-106-149-109.carlnfd1.nsw.optusnet.com.au (c122-106-149-109.carlnfd1.nsw.optusnet.com.au [122.106.149.109]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 5BB9E1A6AC2; Sat, 3 Sep 2016 16:41:59 +1000 (AEST) Date: Sat, 3 Sep 2016 16:41:58 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin cc: FreeBSD-arch Arch Subject: Re: pause_ms() wrapper In-Reply-To: <2960854.iLOY0Gxipb@ralph.baldwin.cx> Message-ID: <20160903152718.O1061@besplex.bde.org> References: <2960854.iLOY0Gxipb@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=EfU1O6SC c=1 sm=1 tr=0 a=R/f3m204ZbWUO/0rwPSMPw==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=kIGO7mLrGqZs1d1fG2kA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 06:42:11 -0000 On Fri, 2 Sep 2016, John Baldwin wrote: > Figuring out the 3 arguments required for pause_sbt() can be a bit > non-obvious (at least to me). To that end, I'd like to have a simple > wrapper around pause_sbt() that accepts milliseconds. It would align > itself on hardclock similar to the hz-based wrapper. OTOH, we could > change the implementation at some point to use something more resaonable > in terms of precision, etc. However, most of the time when I want to > sleep for N milliseconds (or N microseconds) due to some hardware spec, > I don't really have a strong opinion on the precision. Having all the > callers try to figure out a precision would seem to inevitably result > in inconsistencies. To start with I'd like to just add this: I complained to mav about the difficult of controlling precision. The defaults work poorly. There are too many too complicated options to override the defaults, but not enough not complicated enough to do what I want. E.g., the 5% default error is too large for long timeouts, but there is no way to reduce it for long timeouts -- the options only allow you to increase it further. > #define pause_ms(wmesg, msecs) \ > pause_sbt((wmesg), SBT_1MS * (msecs), 0, C_HARDCLOCK) Here C_HARDCLOCK is supposed to give compatibility with old periodic hardclock. It doesn't do that. With a requested timeout of n ticks, old periodic hardclock gives a timeout of 1 fractional ticks (average 1/2) and n-1 full ticks and it was possible to sync with or predict when the ticks would occur and adjust n up or down by 1 to compenstae the fractional tick. C_HARDCLOCK with a requested timeout of n ticks gives a timeout of at least n ticks, extended by the system's best attempt to not much more than N%, where N defaults to 5 but can be changed by the sysadmin. This magic 5 and the sysctl are not documented in any man page. Often, 5% is much more accuracy that needed, but asking for less is even more complicated than asking for more. First you have to do something to avoid the default having precedence. For some APIs, C_HARDCLOCK is the default 'flags' is 0, so you have to use C_PREL() to avoid it. C_PREL(32) gives a tiny percentages so allows the 'pr' parameter (0 here) to dominate. The 2 precision parameters mostly give complications by getting in each other's way. > Which you can use as 'pause_ms("pcieflr", 100);'. > > Are there any objections? Do people want other wrappers? Should we > use more nuanced math similar to what was done in r296775? There should also be a wrapper for the usual case of setting up a callout, with a good name like "timeout". callout_reset() was already too complicated and badly named (it is more related to times than calls, and more related to [re]starting than resetting (clearing)). But it is trivial compared with callout_reset_sbt_on(). I don't actually like the macro. Most callout functions are already macros several layers deep leading to callout_reset_sbt_on(). This was painful to debug with ddb. r296775 has no effect for most uses. The error is usually 5%. I think sloppiness on the old scaling usually gave much smaller errors. Bruce