From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751348AbcFWN6I (ORCPT ); Thu, 23 Jun 2016 09:58:08 -0400 Received: from ns.sciencehorizons.net ([71.41.210.147]:13378 "HELO ns.sciencehorizons.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750957AbcFWN6F (ORCPT ); Thu, 23 Jun 2016 09:58:05 -0400 Date: 23 Jun 2016 09:58:03 -0400 Message-ID: <20160623135803.636.qmail@ns.sciencehorizons.net> From: "George Spelvin" To: chrubis@suse.cz, tglx@linutronix.de Subject: Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel Cc: arjan@infradead.org, clm@fb.com, edumazet@google.com, fweisbec@gmail.com, lenb@kernel.org, linux-kernel@vger.kernel.org, linux@sciencehorizons.net, ltp@lists.linux.it, mingo@kernel.org, paulmck@linux.vnet.ibm.com, peterz@infradead.org, riel@redhat.com, rt@linutronix.de, torvalds@linux-foundation.org, umgwanakikbuti@gmail.com In-Reply-To: <20160623114759.GA19250@rei.lan> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Cyril Hrubis wrote: > Thomas Gleixner wrote: >> Err. You know that the timer expired because sigtimedwait() returns >> EAGAIN. And the only thing you can reliably check for is that the timer did >> not expired to early. Anything else is guesswork and voodoo programming. > But seriously is there a reason > why OS that is not under heavy load cannot expire timers with reasonable > overruns? I.e. if I ask for a second of sleep and expect it to be woken > up not much more than half of a second later? > If we stick only to guarantees that are defined in POSIX playing music > with mplayer would not be possible since it sleeps in futex() and if it > wakes too late it will fail to fill buffers. In practice this worked > fine for me for years. Two points: 1) sigtimedwait() is unusual in that it uses the jiffies timer. Most system call timeouts (including specifically the one in FUTEX_WAIT) use the high-resolution timer subsystem, which is a whole different animal with tighter guarantees, and 2) The worst-case error in tglx's proposal is 1/8 of the requested timeout: the wakeup is after 112.5% of the requested time, plus one tick. This is well within your requested accuracy. (For very short timeouts, the "plus one tick" can dominate the percentage error.)