Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753926AbbEUGOP (ORCPT ); Thu, 21 May 2015 02:14:15 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:36553 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752788AbbEUGOM (ORCPT ); Thu, 21 May 2015 02:14:12 -0400 Date: Thu, 21 May 2015 08:14:08 +0200 From: Ingo Molnar To: John Stultz Cc: LKML , Thomas Gleixner , Peter Zijlstra , Prarit Bhargava , Richard Cochran Subject: Re: [PATCH 3/7] time: Rework debugging variables so they aren't global Message-ID: <20150521061408.GA11077@gmail.com> References: <1432142376-2077-1-git-send-email-john.stultz@linaro.org> <1432142376-2077-4-git-send-email-john.stultz@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432142376-2077-4-git-send-email-john.stultz@linaro.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1470 Lines: 47 * John Stultz wrote: > Ingo suggested that the timekeeping debugging variables > recently added should not be global, and should be tied > to the timekeeper's read_base. > > Thus this patch implements that suggestion. > > This version is differnet from the earlier versions s/differnet/ different > as it keeps the variables in the timekeeper structure > rather then in the tkr. > + * @last_warning: Warning ratelimiter (DEBUG_TIMEKEEPING) > + * @underflow_seen: Underflow warning flag (DEBUG_TIMEKEEPING) > + * @overflow_seen: Overflow warning flag (DEBUG_TIMEKEEPING) > * > * Note: For timespec(64) based interfaces wall_to_monotonic is what > * we need to add to xtime (or xtime corrected for sub jiffie times) > @@ -106,6 +109,18 @@ struct timekeeper { > s64 ntp_error; > u32 ntp_error_shift; > u32 ntp_err_mult; > +#ifdef CONFIG_DEBUG_TIMEKEEPING > + long last_warning; > + /* > + * These simple flag variables are managed > + * without locks, which is racy, but ok since > + * we don't really care about being super > + * precise about how many events were seen, > + * just that a problem was observed. s/but ok since/ but they are ok since Thanks, Ingo -- 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/