From owner-freebsd-arch@freebsd.org Fri Sep 2 19:22:54 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 980F4BCDA8B for ; Fri, 2 Sep 2016 19:22:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A1E3ACE for ; Fri, 2 Sep 2016 19:22:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id B136810A999 for ; Fri, 2 Sep 2016 15:22:51 -0400 (EDT) From: John Baldwin To: FreeBSD-arch Arch Subject: pause_ms() wrapper Date: Fri, 02 Sep 2016 12:22:42 -0700 Message-ID: <2960854.iLOY0Gxipb@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 02 Sep 2016 15:22:51 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean 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: Fri, 02 Sep 2016 19:22:54 -0000 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: #define pause_ms(wmesg, msecs) \ pause_sbt((wmesg), SBT_1MS * (msecs), 0, C_HARDCLOCK) 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? -- John Baldwin From owner-freebsd-arch@freebsd.org Sat Sep 3 02:32:58 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 8068FBCDD84 for ; Sat, 3 Sep 2016 02:32:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C348EFE; Sat, 3 Sep 2016 02:32:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x236.google.com with SMTP id e124so69955690ith.0; Fri, 02 Sep 2016 19:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T1oT2z73EsikDnWitpxMfdOeDh5eSck0IMDCPVW9uRY=; b=KrziIIVlmCzAnP0/BfQvjijI0XIgjSAtvcb8q8FjydYsTi/896u+1den1ZlCPJvjNG sBZ4GeevltzB+7y//tmBtiGmQ0WunZXCYdjk0v5MYASM++fq181zOrDZ3CnqAPoNk9G2 zVrvZ3hBh+KrXnvRnVi4hGvEBCsH7KB+E+w/bXm8Q0802zZQLKikSO02bxvHkMgbn/U3 k0l53kVq1+oDcP2/AkksJ2iju0B5WtT7EnXWmuZuC750CpbjMT8qfxIv1SSQusjod5jW f0/LopWywSZ/wG/SBWsEt7S6T8SFEwAYilZ9FO5WAykIh4ArnBKofjOwtGoYRJLuP54b aHzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T1oT2z73EsikDnWitpxMfdOeDh5eSck0IMDCPVW9uRY=; b=l6Eqa4pYq0gGDzhjqP1VCq0sZexMka5i6NHmnzCcfWWtaybOawX1qeCUZp09XKgfBc AfmBEeN6DMHn11363va/8jUatICJq02Qn6p6eoZVnD9pMk4lKPeeU2riiBN6FE0QJwQh 8a5xu9XOZkOydA4oGgZJrv8jqPbHVQdvRj2MtiQWKMC7q0gobCcb7KHRWqlI8J6qbP8B t2Oca4aHUfi7tQ4aNTBLLfaZa1wu1UOL0bSCTYPRtghB+Mupsf/pSMR/Y6rhg9UsZQJG qh/babnKQeOytEJJ2eTBmwCNGYGcMMAJAK/9c+kORejAdPIgxLxc0VH4vZ5dSTCBZY5k 4QfA== X-Gm-Message-State: AE9vXwPbldaEFeHL8JGdOYdVUEUUh7pb9QoGjCy3u/oTi6vaou39NDD5QjHSWIx9+OFpl++KHo+fJ5sicc0N6A== X-Received: by 10.36.124.141 with SMTP id a135mr8267532itd.25.1472869977307; Fri, 02 Sep 2016 19:32:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.141.129 with HTTP; Fri, 2 Sep 2016 19:32:56 -0700 (PDT) In-Reply-To: <2960854.iLOY0Gxipb@ralph.baldwin.cx> References: <2960854.iLOY0Gxipb@ralph.baldwin.cx> From: Adrian Chadd Date: Fri, 2 Sep 2016 19:32:56 -0700 Message-ID: Subject: Re: pause_ms() wrapper To: John Baldwin Cc: FreeBSD-arch Arch Content-Type: text/plain; charset=UTF-8 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 02:32:58 -0000 Can we please name it something that indicates it's not designed to be exact? The .. exactness of various calls has been a thorn in the side of a few people, myself included. I've been bitten by the callout precision changes :( I like linux's usleep_range() for example. It makes it obvious that you can get anything inside that bar. How hard is that to do with pause_sbt() ? -adrian On 2 September 2016 at 12:22, 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: > > #define pause_ms(wmesg, msecs) \ > pause_sbt((wmesg), SBT_1MS * (msecs), 0, C_HARDCLOCK) > > 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? > > -- > John Baldwin > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" 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