From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98491C6FA8F for ; Thu, 24 Aug 2023 13:10:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237536AbjHXNJ6 (ORCPT ); Thu, 24 Aug 2023 09:09:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240977AbjHXNJt (ORCPT ); Thu, 24 Aug 2023 09:09:49 -0400 Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EA4A6198A for ; Thu, 24 Aug 2023 06:09:44 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id ca18e2360f4ac-79277cfc73bso7273139f.1 for ; Thu, 24 Aug 2023 06:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1692882584; x=1693487384; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=IQQpR3MAafD1THOWkmLsuJVXQvtSFGGapULogd1q9ek=; b=Ld4hokF01xieggHdn+kNcOXxfwADeQCtK+5AZ+pdXQA94BzW1G+k68NfgkbLG89UDk zNKe5bqt8X1IrPbo6ehcdjhVV5z/l86/3mYZS0Z0rrXRV1MXdRp0oUwZYaCjCSyRJR5R k9gH5GqGvXRuytxGe+zOPMTrmEXa+1W1ZfIgQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692882584; x=1693487384; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IQQpR3MAafD1THOWkmLsuJVXQvtSFGGapULogd1q9ek=; b=MqxPReVkJngnT9iQOdtROv7FJ7msb6XpIuJAwHJis2Kokpqqx23i+0MNsSArbpKGDF FUASzSVdgLe/h1NC7kUu0Mc3TC1eMWafjhU3dXFaGoLf+rs4cPi6xzQiP3RCuLDAsOta ukzsq7Nr3U/bfWREeXVSujFDKuNUqEvsAMnQtFmtwb0qHlLgvihZ3SCapuy3y2vYHNDC gUZN5s5gM9oqNRCmzmWDpMBQNAWyqchhFAgKkIs487Gpg7LEx3iIiTUQ5LjQzCNLRK+N DruP5YBoljaAI28hxaoL6eipvJ0B+Mt1RbsmI2nrvc/5fBWJdqKu0y2k6yQulgOVN4jn zxTQ== X-Gm-Message-State: AOJu0Yy5W2JRSS+E3r8ArTC8EjNytjqNhcQR8tOVh/MPsgxeoFkPqPED qYST8+FqPXV4bGhvopciZKq8Pw== X-Google-Smtp-Source: AGHT+IEC2LoFxn9FbGroATYlp69itwV5taaqzDJRKV1XbKzCcjlBXmDZy1vtRhSXoDijm4XHZYEi6A== X-Received: by 2002:a6b:dc0c:0:b0:792:70f2:a8ed with SMTP id s12-20020a6bdc0c000000b0079270f2a8edmr1593060ioc.4.1692882584151; Thu, 24 Aug 2023 06:09:44 -0700 (PDT) Received: from localhost (156.190.123.34.bc.googleusercontent.com. [34.123.190.156]) by smtp.gmail.com with ESMTPSA id u3-20020a02cbc3000000b0043167542398sm4573459jaq.141.2023.08.24.06.09.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Aug 2023 06:09:43 -0700 (PDT) Date: Thu, 24 Aug 2023 13:09:42 +0000 From: Joel Fernandes To: "Paul E. McKenney" Cc: Huacai Chen , Thomas Gleixner , Z qiang , Huacai Chen , Frederic Weisbecker , Neeraj Upadhyay , Josh Triplett , Boqun Feng , Ingo Molnar , John Stultz , Stephen Boyd , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Sergey Senozhatsky , rcu@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Binbin Zhou Subject: Re: [PATCH V4 2/2] rcu: Update jiffies in rcu_cpu_stall_reset() Message-ID: <20230824130942.GA3810470@google.com> References: <5777BD82-2C8D-4BAB-BDD3-C2C003DC57FB@joelfernandes.org> <87ttspct76.ffs@tglx> <03fe7084-0509-45fa-87ee-8f8705a221a6@paulmck-laptop> <16827b4e-9823-456d-a6be-157fbfae64c3@paulmck-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16827b4e-9823-456d-a6be-157fbfae64c3@paulmck-laptop> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, Aug 24, 2023 at 04:40:42AM -0700, Paul E. McKenney wrote: > On Thu, Aug 24, 2023 at 10:50:41AM +0800, Huacai Chen wrote: > > Hi, Paul, > > > > On Thu, Aug 24, 2023 at 6:41 AM Paul E. McKenney wrote: > > > > > > On Thu, Aug 24, 2023 at 12:03:25AM +0200, Thomas Gleixner wrote: > > > > On Thu, Aug 17 2023 at 16:06, Huacai Chen wrote: > > > > > On Thu, Aug 17, 2023 at 3:27 AM Joel Fernandes wrote: > > > > >> > If do_update_jiffies_64() cannot be used in NMI context, > > > > >> > > > > >> Can you not make the jiffies update conditional on whether it is > > > > >> called within NMI context? > > > > > > > > Which solves what? If KGDB has a breakpoint in the jiffies lock held > > > > region then you still dead lock. > > > > > > > > >> I dislike that.. > > > > > Is this acceptable? > > > > > > > > > > void rcu_cpu_stall_reset(void) > > > > > { > > > > > unsigned long delta; > > > > > > > > > > delta = nsecs_to_jiffies(ktime_get_ns() - ktime_get_coarse_ns()); > > > > > > > > > > WRITE_ONCE(rcu_state.jiffies_stall, > > > > > jiffies + delta + rcu_jiffies_till_stall_check()); > > > > > } > > > > > > > > > > This can update jiffies_stall without updating jiffies (but has the > > > > > same effect). > > > > > > > > Now you traded the potential dead lock on jiffies lock for a potential > > > > live lock vs. tk_core.seq. Not really an improvement, right? > > > > > > > > The only way you can do the above is something like the incomplete and > > > > uncompiled below. NMI safe and therefore livelock proof time interfaces > > > > exist for a reason. > > > > > > Just for completeness, another approach, with its own advantages > > > and disadvantage, is to add something like ULONG_MAX/4 to > > > rcu_state.jiffies_stall, but also set a counter indicating that this > > > has been done. Then RCU's force-quiescent processing could decrement > > > that counter (if non-zero) and reset rcu_state.jiffies_stall when it > > > does reach zero. > > > > > > Setting the counter to three should cover most cases, but "live by the > > > heuristic, die by the heuristic". ;-) > > > > > > It would be good to have some indication when gdb exited, but things > > > like the gdb "next" command can make that "interesting" when applied to > > > a long-running function. > > > > The original code is adding ULONG_MAX/2, so adding ULONG_MAX/4 may > > make no much difference? The simplest way is adding 300*HZ, but Joel > > dislikes that. > > I am not seeing the ULONG_MAX/2, so could you please point me to that > original code? > > The advantage of ULONG_MAX/4 over ULONG_MAX/2 is that the time_after() > and time_before() macros have ULONG_MAX/4 slop in either direction > before giving you the wrong answer. You can get nearly the same result > using ULONG_MAX/2, but it requires a bit more care. And even on 32-bit > HZ=1000 systems, ULONG_MAX/4 gets you more than 12 days of gdb session > or jiffies-update delay before you start getting false positives. > > Then things can be reset after (say) 3 calls to rcu_gp_fqs() and > also the current reset at the beginning of a grace period, which > is in record_gp_stall_check_time(). I like Paul's suggestion a lot except that if someone sets a breakpoint right when the jiffies is being reset, so then we have to come back to doing Thomas's suggestion. So maybe a combination of Paul's and Thomas's suggestions (of using last_jiffies_update with the NMI-safe timestamp read) may work. > It would be better if RCU could get notified at both ends of the debug > session, but given gdb commands such as "next", along with Thomas's > point about gdb breakpoints being pretty much anywhere, this might or > might not be so helpful in real life. But worth looking into. True, I was curious if rcu_cpu_stall_reset() can be called on a tickless kernel as well before jiffies gets a chance to update, in which case I think your suggestion of biasing the stall time and later resetting it would help a lot for such situations. thanks, - Joel > Thanx, Paul > > > Huacai > > > > > > > > Thanx, Paul > > > > > > > Thanks, > > > > > > > > tglx > > > > --- > > > > --- a/kernel/time/tick-sched.c > > > > +++ b/kernel/time/tick-sched.c > > > > @@ -51,6 +51,13 @@ struct tick_sched *tick_get_tick_sched(i > > > > */ > > > > static ktime_t last_jiffies_update; > > > > > > > > +unsigned long tick_estimate_stale_jiffies(void) > > > > +{ > > > > + ktime_t delta = ktime_get_mono_fast_ns() - READ_ONCE(last_jiffies_update); > > > > + > > > > + return delta < 0 ? 0 : div_s64(delta, TICK_NSEC); > > > > +} > > > > + > > > > /* > > > > * Must be called with interrupts disabled ! > > > > */ > > > > > > > >