From owner-freebsd-hackers@freebsd.org Thu Dec 15 04:18:34 2016 Return-Path: Delivered-To: freebsd-hackers@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 E0C44C81670 for ; Thu, 15 Dec 2016 04:18:34 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5DDFC6B for ; Thu, 15 Dec 2016 04:18:34 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 9267135b-c27d-11e6-9f67-d3961ed5a660 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 9267135b-c27d-11e6-9f67-d3961ed5a660; Thu, 15 Dec 2016 04:18:46 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBF4IV15005076; Wed, 14 Dec 2016 21:18:31 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481775511.1889.450.camel@freebsd.org> Subject: Re: How to use sem_timedwait? From: Ian Lepore To: Goran =?iso-8859-2?Q?Meki=E6?= Cc: freebsd-hackers@freebsd.org Date: Wed, 14 Dec 2016 21:18:31 -0700 In-Reply-To: <20161215002906.mllorgvvuovbdtze@hal9000.meka.no-ip.org> References: <20161214074228.zh6q5zya2gszw4g6@hal9000.meka.no-ip.org> <1481748960.1889.398.camel@freebsd.org> <20161215002906.mllorgvvuovbdtze@hal9000.meka.no-ip.org> Content-Type: text/plain; charset="iso-8859-2" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 04:18:35 -0000 On Thu, 2016-12-15 at 01:29 +0100, Goran Mekiĉ wrote: > On Wed, Dec 14, 2016 at 01:56:00PM -0700, Ian Lepore wrote: > > > > On Wed, 2016-12-14 at 08:42 +0100, Goran Mekiĉ wrote: > > One of the things you did with that code is measured how much time > > it > > took to format and print the "It should have ended..." line.  If > > you > > want to capture how long you were asleep you need the > > clock_gettime() > > to be the next thing you call after sem_timedwait().  Even the time > > to > > access errno may be non-trivial if it's actually a thread-local > > variable. > > > > If you want to get better sleep-timing performance (at the expense > > of > > less power-saving efficiency), try setting > > > >   sysctl kern.timecounter.alloweddeviation=0 > > > > That will prevent the aggregation of timeouts scheduled near each > > other > > to all happen at the same time, resulting in more wakeups, each of > > which is more accurate (more wakeups = more power used). > > > > -- Ian > > > This is exactly what I've needed. Thank you so much. If you can tell > me any other tip to make the difference even smaller, I'd be > grateful. Currently, it goes from 0.1ms to 1ms. Great improvement! > Once more, thank you very much! > > Regards, > meka Do you actually need semaphore behavior along with the precise sleeping, or are you just using it because it is a convenient function that takes a timespec/nanosecs wait time? Making a guess here:  Is your actual goal to wake up periodically with the period between wakeups as accurate as possible?  If so, a better mechanism might be to use kqueue(2)/kevent(2) with EVFILT_TIMER events.  With EVFILT_TIMER events, the wakeups are scheduled as if aligned to a grid -- even if one wakeup is a bit late due to system workload, the next wakeup after it will still be properly aligned to the original grid.  For example, if you ask for a wakeup once per millisecond and some wake happens after 1.2mS, the next wakeup will be .8mS after that; the phase of the wakeups doesn't shift over time. -- Ian