From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753771AbbDBSnX (ORCPT ); Thu, 2 Apr 2015 14:43:23 -0400 Received: from casper.infradead.org ([85.118.1.10]:38674 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753736AbbDBSnT (ORCPT ); Thu, 2 Apr 2015 14:43:19 -0400 Date: Thu, 2 Apr 2015 20:43:17 +0200 From: Peter Zijlstra To: John Stultz Cc: lkml , Ingo Molnar , Thomas Gleixner , Prarit Bhargava , Richard Cochran Subject: Re: [PATCH 19/21] clocksource: Improve comment explaining clocks_calc_max_nsecs()'s 50% safety margin Message-ID: <20150402184317.GD27490@worktop.programming.kicks-ass.net> References: <1427945681-29972-1-git-send-email-john.stultz@linaro.org> <1427945681-29972-20-git-send-email-john.stultz@linaro.org> <20150402085011.GJ21418@twins.programming.kicks-ass.net> <20150402183447.GC27490@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 02, 2015 at 11:41:15AM -0700, John Stultz wrote: > On Thu, Apr 2, 2015 at 11:34 AM, Peter Zijlstra wrote: > > On Thu, Apr 02, 2015 at 10:30:18AM -0700, John Stultz wrote: > >> > Should we make a further note that the tk_fast things rely on this > >> > slack since they're not strongly serialized against this? That is, they > >> > can end up using an older cycle_last value and therefore end up with a > >> > larger delta than other code. > >> > >> Though, even with the tk_fast bits, we expect the update to happen > >> regularly, its just that for the benefit of lock-free access we are ok > >> with the possible slight inconsistencies (in the mono clock) that > >> could happen if we use a slightly stale value mid-update. So I don't > >> think the tk_fast bits are actually relying on the slack any more then > >> the normal timekeeping code relies on the slack to handle slight > >> delays in processing the updates. If we deal with time deltas large > >> enough to cause overflows, or time intervals larger then the hardware > >> can represent, we're sunk in either case. This 50% margin just makes > >> it easier to catch unexpected delays or issues. > > > > Right, so you're saying that even though the fast bits will see slightly > > larger deltas than the normal code, they should still not get anywhere > > near the 50% because we update much more frequently? > > Well, they may get to 50% or slightly over (since 50% is the max nohz > idle length), but that's likely rare, and we shouldn't get anywhere > close to real failure edges (100% be it the mult-overflow or hardware > mask limit). Right, so the fast thing rely on there being slack. That was my point rather. I know they'll not get to the end of slack.