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 5FD78C6FD1F for ; Thu, 16 Mar 2023 13:28:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230346AbjCPN2x (ORCPT ); Thu, 16 Mar 2023 09:28:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230332AbjCPN2r (ORCPT ); Thu, 16 Mar 2023 09:28:47 -0400 Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03D4B6F48F for ; Thu, 16 Mar 2023 06:28:43 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id r5so1636128qtp.4 for ; Thu, 16 Mar 2023 06:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1678973323; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=mq05T+mqYchdO6eVgaCmPyYAruAZx/QKv/nYoCC7GvE=; b=gtIvtqKZjbnizmS8t3q0lgTHjhzQuSiektGAU7yoNCrCEGjyt74+35bI9cf/AouYOg i9q2/s2WPzwpd10R0HLiYLs9GXw2M8MNKrIspd2LMnciGoj/JjZAgoWmSVO2GCZIwR4N whaHxtw3NlKu4M3za5UQkxHLEkj1CzxdB+Yrc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678973323; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mq05T+mqYchdO6eVgaCmPyYAruAZx/QKv/nYoCC7GvE=; b=jhh4ICQzB6G75Pap/YblzhPjIoN87bP8HssFoSfx93ezo7nTcoLh6IE+cUSwjwik+7 zuA2GKfHLZOJ7DTrmPlPoPGnOCqPqen+pteUrgbeu0Xk4P6bvFGfSmbp6hnGAVTgqWZO WBghdO1qOyPyviWE0IAas9S+uqMZNmNWaPC90DzWzh6eFsmahCTAx84qthOJRZBogK5x zWFn8BFegZ/AZ+/cJlyEZGyP+yDvPCNNLeXfDW2RGvTSj3MGmWDQL0J6qoDvZGC9cDC9 zgVMVpHtNkQNZnxJpTBYejn/36+HL4b05sVNo1QJuTTNqtQqtKkUV99bKhmn7NO+UsEI 4oeg== X-Gm-Message-State: AO0yUKWBuJ6fN34leYr8vkqKbWbRbyT5letpcB5UGyCLKFP8HLZt8YVm +aGlETMZunM1mzRfr5XaCwmgtExkGhUjvpHHmZg= X-Google-Smtp-Source: AK7set8shGyWYizyY6RNgWTdQAw4vWEX0VNS0sxE9of5pEe8x9LdR1zyuafDT2JKIuNlsh1wANUj6g== X-Received: by 2002:a05:622a:14cb:b0:3d5:1fc6:587b with SMTP id u11-20020a05622a14cb00b003d51fc6587bmr6471346qtx.18.1678973322822; Thu, 16 Mar 2023 06:28:42 -0700 (PDT) Received: from smtpclient.apple ([2600:1003:b840:cfc9:d51f:7877:7172:21f6]) by smtp.gmail.com with ESMTPSA id de21-20020a05620a371500b007422fd3009esm5994590qkb.20.2023.03.16.06.28.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Mar 2023 06:28:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Joel Fernandes Mime-Version: 1.0 (1.0) Subject: Re: [PATCH 1/1] rcu/rcuscale: Stop kfree_scale_thread thread(s) after unloading rcuscale Date: Thu, 16 Mar 2023 09:28:31 -0400 Message-Id: <2B9F2C1A-B274-41EF-8ABE-1E660521BCE4@joelfernandes.org> References: Cc: paulmck@kernel.org, Frederic Weisbecker , Josh Triplett , Neeraj Upadhyay , Davidlohr Bueso , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , rcu@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: To: "Zhuo, Qiuxu" X-Mailer: iPhone Mail (20B101) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Mar 16, 2023, at 9:17 AM, Zhuo, Qiuxu wrote: >=20 > =EF=BB=BF >>=20 >> From: Paul E. McKenney >> [...] >>>>=20 >>>> How about to pull the rcu_scale_cleanup() function after >> kfree_scale_cleanup(). >>>> This groups kfree_* functions and groups rcu_scale_* functions. >>>> Then the code would look cleaner. >>>> So, do you think the changes below are better? >>>=20 >>> IMHO, I don't think doing such a code move is better. Just add a new >>> header file and declare the function there. But see what Paul says >>> first. >>=20 >> This situation is likely to be an early hint that the kvfree_rcu() testin= g should >> be split out from kernel/rcu/rcuscale.c. >=20 > Another is that it's a bit expensive to create a new header file just for=20= > eliminating a function declaration. ;-) What is so expensive about new files? It is a natural organization structure= . > So, if no objections, I'd like to send out the v2 patch with the updates b= elow: >=20 > - Move rcu_scale_cleanup() after kfree_scale_cleanup() to eliminate the > declaration of kfree_scale_cleanup(). Though this makes the patch bigg= er,=20 > get the file rcuscale.c much cleaner. >=20 > - Remove the unnecessary step "modprobe torture" from the commit message= . >=20 > - Add the description for why move rcu_scale_cleanup() after > kfree_scale_cleanup() to the commit message. Honestly if you are moving so many lines around, you may as well split it ou= t into a new module. The kfree stuff being clubbed in the same file has also been a major annoyan= ce. - Joel=20 > Thanks! > -Qiuxu >=20 >> [...]