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 33E36C83F17 for ; Tue, 29 Aug 2023 04:08:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234918AbjH2EIN (ORCPT ); Tue, 29 Aug 2023 00:08:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233981AbjH2EIE (ORCPT ); Tue, 29 Aug 2023 00:08:04 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1400BD; Mon, 28 Aug 2023 21:08:01 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 43CAB617C9; Tue, 29 Aug 2023 04:08:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4E79C433CB; Tue, 29 Aug 2023 04:08:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1693282080; bh=Yo/1OpFbUF2M6wOhA1RLEhxC+KWTlVLoD+XnYgqbHYg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=irN+3jF9LN2VUTDfjRyJsZJNR0Zu97FSoQOK+RwPIFARRzYrh9ZYSdRUWtwjxRDvs bvhQrohaQbNkFywM7W15EIaCOlxHDKP9hcKPB3CrbysUzRRWI1GaeOoWmHsWAr3/h/ YOSEz18RxFS76mVAbxF7VUFVdEem341+E7HFjlKOlh17DdN0e2C0Y84B9+5lg19UNL N4eGz3EP/8qRIBN2McJCiyY2LnGuR17YO4MLieJrYDiQ7BwBV+Q1koguBSCLsASYdj 7Bq0B5VAVCkkVbvWHnsAKbyvAS9eZB8HzOw6iT5ZvCLtRUDXvtRzSN3Y2jqhUbkhY2 IQEI5L2SD9+Lg== Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-99bdeae1d0aso502058266b.1; Mon, 28 Aug 2023 21:08:00 -0700 (PDT) X-Gm-Message-State: AOJu0YyNjU3w+CIYrv5wghGEUwFdFNPpnqh/IU0H95nKRi0KkkBvnWHT hG6f6oMknpBxLoO2JyW3zf89NyJPb9Ts+1kc+pk= X-Google-Smtp-Source: AGHT+IEugUtZjdtVJqio2CQ6W8LQxEzy3rliFmZBmcTMUiA+b2EuJxvBrnP8kCbFz5qSTtDne3bEtoonIchoCdctQv0= X-Received: by 2002:a17:906:7395:b0:9a1:f73b:90ce with SMTP id f21-20020a170906739500b009a1f73b90cemr12929181ejl.54.1693282078841; Mon, 28 Aug 2023 21:07:58 -0700 (PDT) MIME-Version: 1.0 References: <8792da20-a58e-4cc0-b3d2-231d5ade2242@paulmck-laptop> <24e34f50-32d2-4b67-8ec0-1034c984d035@paulmck-laptop> <20230825232807.GA97898@google.com> <2681134d-cc88-49a0-a1bc-4ec0816288f6@paulmck-laptop> <20230828133348.GA1553000@google.com> <142b4bff-6a2e-4ea0-928c-3cfe9befa403@paulmck-laptop> In-Reply-To: From: Huacai Chen Date: Tue, 29 Aug 2023 12:07:46 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V4 2/2] rcu: Update jiffies in rcu_cpu_stall_reset() To: Joel Fernandes Cc: paulmck@kernel.org, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Joel, On Tue, Aug 29, 2023 at 4:47=E2=80=AFAM Joel Fernandes wrote: > > Hi Huacai, > > On Mon, Aug 28, 2023 at 11:13=E2=80=AFAM Huacai Chen wrote: > > > [...] > > > > > > > [Huacai] > > > > I also think the original patch should be OK, but I have another > > > > question: what will happen if the current GP ends before > > > > nr_fqs_jiffies_stall reaches zero? > > > > > > Nothing should happen. Stall detection only happens when a GP is in > > > progress. If a new GP starts, it resets nr_fqs_jiffies_stall. > > > > > > Or can you elaborate your concern more? > > OK, I will test your patch these days. Maybe putting > > nr_fqs_jiffies_stall before jiffies_force_qs is better, because I > > think putting an 'int' between two 'long' is wasting space. :) > > That's a good point and I'll look into that. Another point, is it better to replace ULONG_MAX with ULONG_MAX/4 as Paul suggested? > > Meanwhile I pushed the patch out to my 6.4 stable tree for testing on my = fleet. > > Ideally, I'd like to change the stall detection test in the rcutorture > to actually fail rcutorture if stalls don't happen in time. But at > least I verified this manually using rcutorture. > > I should also add a documentation patch for stallwarn.rst to document > the understandable sensitivity of RCU stall detection to jiffies > updates (or lack thereof). Or if you have time, I'd appreciate support > on such a patch (not mandatory but I thought it would not hurt to > ask). > > Looking forward to how your testing goes as well! I have tested, it works for KGDB. Huacai > > thanks, > > - Joel