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"