Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932345AbbLNMkB (ORCPT ); Mon, 14 Dec 2015 07:40:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54800 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932241AbbLNMj7 (ORCPT ); Mon, 14 Dec 2015 07:39:59 -0500 Date: Mon, 14 Dec 2015 13:39:58 +0100 From: Miroslav Lichvar To: John Stultz Cc: lkml , Thomas Gleixner , Richard Cochran , Prarit Bhargava , Andy Lutomirski Subject: Re: [RFC][PATCH v2] timekeeping: Cap adjustments so they don't exceed the maxadj value Message-ID: <20151214123958.GB21828@localhost> References: <1449777241-22051-1-git-send-email-john.stultz@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1449777241-22051-1-git-send-email-john.stultz@linaro.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1540 Lines: 38 On Thu, Dec 10, 2015 at 11:54:01AM -0800, John Stultz wrote: > Thus its been occasionally noted that users have seen > confusing warnings like: > > Adjusting tsc more than 11% (5941981 vs 7759439) > @@ -1612,13 +1615,32 @@ static __always_inline void timekeeping_freqadjust(struct timekeeper *tk, > /* preserve the direction of correction */ > negative = (tick_error < 0); > > - /* Sort out the magnitude of the correction */ > + /* If any adjustment would pass the max, just return */ > + if (negative && (cur_adj - 1) < (base - max)) > + return; > + if (!negative && (cur_adj + 1) > (base + max)) > + return; I ran the test that triggered the warning previously and it was silent now. But it looks like timekeeping_adjust() should check the adjustment too before calling timekeeping_apply_adjustment(). In linux-tktest I was able to find a configuration (-t 10 -n 150 -p 10000000) that triggered the warning again. I'm not sure how likely it is to happen in real world and if it's worth fixing though. To avoid adding even more code, maybe the check could be moved to timekeeping_apply_adjustment()? It would try decreasing adj_scale until the check passes. When it reached -1, the function would return immediately with no adjustment of the multiplier. -- Miroslav Lichvar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/