Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp631207pxh; Wed, 10 Nov 2021 07:08:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJzFHAn1i8Jq5ymMj9KSOh7oeJyi+VtpUzqNWV6Wcs5kiHHA60xHGl3cWq5bdIxCkJ1hYcOs X-Received: by 2002:a17:902:8302:b0:143:6e5f:a4a0 with SMTP id bd2-20020a170902830200b001436e5fa4a0mr14916824plb.20.1636556896588; Wed, 10 Nov 2021 07:08:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636556896; cv=none; d=google.com; s=arc-20160816; b=ldZEtMkfU6saWeIGFLlaprTEuos7bc0mr/9prdZ9ZqusFsk4nitTITfcdoQXAvlWb4 hn8JKDBuq7hNXUFK99BFQGXo/V/Ef4S+lgRtfYNE6dh+G7EmS3SOOc9kZMC2wotIyUuE R9uzqxGbbURSbLcUe3VVmuTBZBRQXM3YheNkT2At9ELB6l6B2JF1qDcMIKg/IsdhNq1u VuZ69VDvbO1GGy28htYGKRy+Fe0rZjMvny8FML7CztUkxnjgBEDiruL6QZ7H6feFcV87 us0WywiF34xu5x9crFbHjYi4Q7dzS0+pJF9g/kV4fQ/dFf9VIgJCPyP9MqD7jrmKAnhF aJSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=QmYgLd6YIxlf9pW17Y1yfWAsO8W32NTgwblflNWM8Gk=; b=YsdxQgJfa1OVXG7x3stHpjtRsh2t6PeIcnGql41xX65YL2dk6Ar3UPWHntS3FpUF0F kGN0OskQW3ln0t+vPq84lC/WMmlE/CS9r4jL1GD/zNGIQUQzDoqsKWKvozIM7WjpRYZq q+1KBW8Pik+QO5FQeOcsbt4SAHQMK73wFhCyQI//V2EU0+7EYR5JL5kxCLx5JPXPN9I7 tKnzW4rlYxFm9oMuUhD+/vM9ZR90YGAemjOea0r7HxX7NFU/7rFrq+yGXHTy2/sKi3cG cU5fL/Fr8yZuT5enx6VhSle7I8zfzQA2pYcaZgvgmsi/HKTPiAkx0y/YWbS9EH1DVDnO tOrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=vMwqSGPy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i16si123741pla.42.2021.11.10.07.07.48; Wed, 10 Nov 2021 07:08:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=vMwqSGPy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232405AbhKJPHx (ORCPT + 99 others); Wed, 10 Nov 2021 10:07:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:48036 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232339AbhKJPHk (ORCPT ); Wed, 10 Nov 2021 10:07:40 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9E76561051; Wed, 10 Nov 2021 15:04:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636556692; bh=qtocZ3hkzt64qXgyIeHo10k+iZQM7znfrDaOz+wsqGg=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=vMwqSGPyb2cDGIhmWJQraSt5kCP4cX1rxlLy7Qf1W8w2NcArCGt4gv+f+jNx98oUz BlZdS1nxF9dGOMiYuQzDdLaFO0Xkh58XchNct0I1tOtomLgNYGA/sxYM5AOOgAcfd/ UhY2z4sul/NUYLj6aBFXyfj5c2YHzrT+LO5CUFy2LMurKbwEb4z3gzfwuuvTSLnHZN vk1xSckiI1i2EIZU10a5ZXOmGU6au9amQy+Fe1XU2Yi+5+asgQoWxzHdQNhzaVDXAo EGdjOFyLgsvkNiq/PWj8AY7+CMZdaDgu1cJsPW2/6ki/WSR0ZhV7jBOgVm0V3vjtjB FzWKHnqMOAaOQ== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 711F95C0848; Wed, 10 Nov 2021 07:04:52 -0800 (PST) Date: Wed, 10 Nov 2021 07:04:52 -0800 From: "Paul E. McKenney" To: Heiner Kallweit Cc: John Stultz , Thomas Gleixner , Stephen Boyd , Feng Tang , Linux Kernel Mailing List Subject: Re: [PATCH] clocksource: Improve cs_watchdog_read() Message-ID: <20211110150452.GB641268@paulmck-ThinkPad-P17-Gen-1> Reply-To: paulmck@kernel.org References: <8f13ba8d-03b5-76de-4d59-4ca8786afb83@gmail.com> <20211110124821.GZ641268@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 10, 2021 at 02:53:27PM +0100, Heiner Kallweit wrote: > On 10.11.2021 13:48, Paul E. McKenney wrote: > > On Tue, Nov 09, 2021 at 09:55:08PM +0100, Heiner Kallweit wrote: > >> If max_cswd_read_retries is set to 0 or 1 then the current warning > >> behavior doesn't seem to make too much sense to me. > >> If set to 0, then we'd warn with each watchdog run. > >> If set to 1, then we'd warn at the first retry, even though the commit > >> description of db3a34e17433 states that one retry is expected behavior. > >> If printing a message at all in this case, then it should be debug > >> level. > > > > The behavior for max_cswd_read_retries==1 is exactly what you want when > > you are checking to see whether or not your system would retry at all > > for the duration of a given run. > > > > The behavior for max_cswd_read_retries==0 is exactly what you want when > > you are testing the ability to print that message on a system that will > > not do a retry in a reasonable period of time. > > > > Or am I missing something here? > > > For me this mixes production warning and debug features. I know of no law saying that a given module parameter cannot be used for both debugging and production features. In fact, there are any number of parameters that take ranges of values, some of which should not be used in production. In addition, Linux supports such a wide range of environments and workloads that people supporting different production environments will have very different ideas about the advisability of setting a given value for a given module parameter. So if your production environments don't like setting the value of clocksource.max_cswd_read_retries to less than two, why not just prohibit such settings in your production environments? > To support your debug use cases, maybe use something like this? > > if (nretries > 1) > pr_warn() > else if (nretries >= max_cswd_read_retries) > pr_debug() I am sorry, but I am not seeing the benefit of this change. How does this help you? Thanx, Paul > >> Whilst being at it, move declaration of wd_end and wd_delta into the > >> loop and remove not needed braces. > > > > I am OK with moving those two variables into the "for" loop. > > > > I am personally OK removing the braces, but if I remember correctly, > > my upstream maintainer asked that I add them due to the statement being > > split across two lines. > > > > Thanx, Paul > > > >> Signed-off-by: Heiner Kallweit > >> --- > >> kernel/time/clocksource.c | 6 +++--- > >> 1 file changed, 3 insertions(+), 3 deletions(-) > >> > >> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c > >> index f29d1a524..8c0be9c02 100644 > >> --- a/kernel/time/clocksource.c > >> +++ b/kernel/time/clocksource.c > >> @@ -208,10 +208,11 @@ module_param(verify_n_cpus, int, 0644); > >> static bool cs_watchdog_read(struct clocksource *cs, u64 *csnow, u64 *wdnow) > >> { > >> unsigned int nretries; > >> - u64 wd_end, wd_delta; > >> int64_t wd_delay; > >> > >> for (nretries = 0; nretries <= max_cswd_read_retries; nretries++) { > >> + u64 wd_end, wd_delta; > >> + > >> local_irq_disable(); > >> *wdnow = watchdog->read(watchdog); > >> *csnow = cs->read(cs); > >> @@ -222,10 +223,9 @@ static bool cs_watchdog_read(struct clocksource *cs, u64 *csnow, u64 *wdnow) > >> wd_delay = clocksource_cyc2ns(wd_delta, watchdog->mult, > >> watchdog->shift); > >> if (wd_delay <= WATCHDOG_MAX_SKEW) { > >> - if (nretries > 1 || nretries >= max_cswd_read_retries) { > >> + if (nretries > 1) > >> pr_warn("timekeeping watchdog on CPU%d: %s retried %d times before success\n", > >> smp_processor_id(), watchdog->name, nretries); > >> - } > >> return true; > >> } > >> } > >> -- > >> 2.33.1 > >> >