Message ID | 20230415033159.4249-3-sj@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp810908vqo; Fri, 14 Apr 2023 20:45:01 -0700 (PDT) X-Google-Smtp-Source: AKy350YlVd5Fa+8NDZU0De5hIIijueEHLNkgiOzIMBagbORJnGBx4p4lunmPuadN8okl+2ocKi3e X-Received: by 2002:a05:6a20:8f09:b0:ec:6039:f76f with SMTP id b9-20020a056a208f0900b000ec6039f76fmr10517908pzk.11.1681530300959; Fri, 14 Apr 2023 20:45:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681530300; cv=none; d=google.com; s=arc-20160816; b=ZgttPzrymdLGzWYWdY/OKnWUlFhV0to0jQy4wd5Rs4pFNg5+8IuBO+/TA0ZQjTSYDG VSnkg4QJuc4NP/sPy7AKWIVNNJt8xw2WFLwW4CnbqbF/eD6OJbh5tQkKkO7mSMosAUXg A62agrrt4KU/EoeqNnZc3N6QsKstbrsLxUA9+qKyHd9zWQIWWfq5Uw91F9+95QPYvMuw eWVmVKR4Yp6NBovvVms4g6jzz0A2WA0Z/d5UuF3BXG6peYCXlcLBbG1tVl5rA7E0x9tX 8MOON6YlnIaIkzJAsbQ8XoPShvNlMVhGR370S86VM+f9parRPjB3TqVAnW42tgG5Bl6h IMGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Jx+Ujqv9xlci3zgOsLm36K4JxBhgxmHYx1AwVD9havQ=; b=gedEi5FTY4rXiEcb6KkVv/g8+Ve3uUqL3QsySS1hNCN69xdGfxBJUrXXtj+tidSlqu wNdjTI62XmbJekOk1XJw5Xwi2xOTdzzO8bTy5bYy+gpGMKNgpC3KTLMjq7dCm+AlddBY 32FM6u/Y/mTrzFEvpgrju4NvalvGPd3K0FYi1yUUVAjnXj3GAh3/5/wmd4qYnFvYiX9d L3yvQrXuAeICRqXg8kCpsKwiu+JwYM9vuHLFO2rGPDqfh3tAZvahYFvzK9ELNN0lEp6x so0rga/6dgtg+YK7LdNg9LrqXmhaofADV2r4YRyx00akHI735Dam6Mp4KSpPZOVaLkMu N2Yg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kwTyhhqB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c5-20020a6566c5000000b0050fa04005e6si2480349pgw.412.2023.04.14.20.44.45; Fri, 14 Apr 2023 20:45:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kwTyhhqB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S229931AbjDODcV (ORCPT <rfc822;yuanzuo1009@gmail.com> + 99 others); Fri, 14 Apr 2023 23:32:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229625AbjDODcO (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 14 Apr 2023 23:32:14 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4442119BF for <linux-kernel@vger.kernel.org>; Fri, 14 Apr 2023 20:32:12 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D271B63869 for <linux-kernel@vger.kernel.org>; Sat, 15 Apr 2023 03:32:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B52C6C433D2; Sat, 15 Apr 2023 03:32:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681529531; bh=+XWziO2ua4unQE9zKFAr0FfsCxROiRZNlP1PEGcC0V4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kwTyhhqBaHhovdgbtGcm2bJ6ADe6+zG/8hZF+KwfzHV9UhcaXoTBUvq/WrD+Em6eQ F2MyBPLt/BvcmaWeoFkU8CTWH19xDu35N03OrdsVKObBMcbc/WNfxuCrifnqtmp5Dz AlaCvGVLRhXZTloldkBT5LFZ0WQVTIMltu4lhd4/mwjX5hPWV3Ra5A4gpY65ALjsHc ByiB8zEIvlHLApbU9KjIioeuwc45HvDtZVO+iZQTjgyZw3wajBYcUh8dQ6pMIdB99E n8FXPuAkutINB3TChQ7S9lp5W1LeV/VmevI2DwizELzZDEmimaoPbfvOruyR+q9emN 7UpN8v8nGInSQ== From: SeongJae Park <sj@kernel.org> To: akpm@linux-foundation.org Cc: vbabka@suse.cz, willy@infradead.org, paulmck@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, SeongJae Park <sj@kernel.org> Subject: [PATCH v2 2/2] mm/slab: break up RCU readers on SLAB_TYPESAFE_BY_RCU example code Date: Sat, 15 Apr 2023 03:31:59 +0000 Message-Id: <20230415033159.4249-3-sj@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230415033159.4249-1-sj@kernel.org> References: <20230415033159.4249-1-sj@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763212317124448308?= X-GMAIL-MSGID: =?utf-8?q?1763212317124448308?= |
Series |
mm/slab: trivial fixup for SLAB_TYPESAFE_BY_RCU example code snippet
|
|
Commit Message
SeongJae Park
April 15, 2023, 3:31 a.m. UTC
The SLAB_TYPESAFE_BY_RCU example code snippet is having not tiny RCU
read-side critical section. 'Documentation/RCU/rculist_nulls.rst' has
similar example code snippet, and commit da82af04352b ("doc: Update and
wordsmith rculist_nulls.rst") has broken it. Apply the change to
SLAB_TYPESAFE_BY_RCU example code snippet, too.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
include/linux/slab.h | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
Comments
On Sat, Apr 15, 2023 at 03:31:59AM +0000, SeongJae Park wrote: > The SLAB_TYPESAFE_BY_RCU example code snippet is having not tiny RCU > read-side critical section. 'Documentation/RCU/rculist_nulls.rst' has > similar example code snippet, and commit da82af04352b ("doc: Update and > wordsmith rculist_nulls.rst") has broken it. Apply the change to > SLAB_TYPESAFE_BY_RCU example code snippet, too. so the page cache (eg find_get_entry()) does not follow this "split the RCU critical section" pattern. Should it? What's the benefit?
On Sat, 15 Apr 2023 04:49:44 +0100 Matthew Wilcox <willy@infradead.org> wrote: > On Sat, Apr 15, 2023 at 03:31:59AM +0000, SeongJae Park wrote: > > The SLAB_TYPESAFE_BY_RCU example code snippet is having not tiny RCU > > read-side critical section. 'Documentation/RCU/rculist_nulls.rst' has > > similar example code snippet, and commit da82af04352b ("doc: Update and > > wordsmith rculist_nulls.rst") has broken it. Apply the change to > > SLAB_TYPESAFE_BY_RCU example code snippet, too. > > so the page cache (eg find_get_entry()) does not follow this "split > the RCU critical section" pattern. Should it? What's the benefit? The benefit would be shorter RCU grace period that allows lower memory footprint, iiuc. Whether it should split the section or not would depend on the lookup speed and number of retries, I think. If the total lookup takes a time that long enough to make the grace period too long and therefore the amount of RCU-protected objects that cannot freed due to the grace priod is huge, I think it would better to follow the pattern. Thanks, SJ
On 4/15/23 05:31, SeongJae Park wrote: > The SLAB_TYPESAFE_BY_RCU example code snippet is having not tiny RCU Since "tiny RCU" means something quite specific in the RCU world, it can be confusing to read it in this sense. We could say e.g. "... snippet uses a single RCU read-side critical section for retries"? > read-side critical section. 'Documentation/RCU/rculist_nulls.rst' has > similar example code snippet, and commit da82af04352b ("doc: Update and > wordsmith rculist_nulls.rst") has broken it. "has broken it" has quite different meaning than "has broken it up" :) I guess we could just add the "up", unless someone has an even better wording. > Apply the change to > SLAB_TYPESAFE_BY_RCU example code snippet, too. > > Signed-off-by: SeongJae Park <sj@kernel.org> > --- > include/linux/slab.h | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index b18e56c6f06c..6acf1b7c6551 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -53,16 +53,18 @@ > * stays valid, the trick to using this is relying on an independent > * object validation pass. Something like: > * > + * begin: > * rcu_read_lock(); > - * again: > * obj = lockless_lookup(key); > * if (obj) { > * if (!try_get_ref(obj)) // might fail for free objects > - * goto again; > + * rcu_read_unlock(); > + * goto begin; > * > * if (obj->key != key) { // not the object we expected > * put_ref(obj); > - * goto again; > + * rcu_read_unlock(); > + * goto begin; > * } > * } > * rcu_read_unlock();
Hi Vlastimil, On Mon, 17 Apr 2023 13:05:40 +0200 Vlastimil Babka <vbabka@suse.cz> wrote: > On 4/15/23 05:31, SeongJae Park wrote: > > The SLAB_TYPESAFE_BY_RCU example code snippet is having not tiny RCU > > Since "tiny RCU" means something quite specific in the RCU world, it can be > confusing to read it in this sense. We could say e.g. "... snippet uses a > single RCU read-side critical section for retries"? Looks much better, thank you for this suggestion! > > > read-side critical section. 'Documentation/RCU/rculist_nulls.rst' has > > similar example code snippet, and commit da82af04352b ("doc: Update and > > wordsmith rculist_nulls.rst") has broken it. > > "has broken it" has quite different meaning than "has broken it up" :) I > guess we could just add the "up", unless someone has an even better wording. Good point, thank you for your suggestion! I will apply above suggestion on the next spin. Thanks, SJ > > > Apply the change to > > SLAB_TYPESAFE_BY_RCU example code snippet, too. > > > > Signed-off-by: SeongJae Park <sj@kernel.org> > > --- > > include/linux/slab.h | 8 +++++--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/include/linux/slab.h b/include/linux/slab.h > > index b18e56c6f06c..6acf1b7c6551 100644 > > --- a/include/linux/slab.h > > +++ b/include/linux/slab.h > > @@ -53,16 +53,18 @@ > > * stays valid, the trick to using this is relying on an independent > > * object validation pass. Something like: > > * > > + * begin: > > * rcu_read_lock(); > > - * again: > > * obj = lockless_lookup(key); > > * if (obj) { > > * if (!try_get_ref(obj)) // might fail for free objects > > - * goto again; > > + * rcu_read_unlock(); > > + * goto begin; > > * > > * if (obj->key != key) { // not the object we expected > > * put_ref(obj); > > - * goto again; > > + * rcu_read_unlock(); > > + * goto begin; > > * } > > * } > > * rcu_read_unlock(); >
On Mon, Apr 17, 2023 at 05:26:57PM +0000, SeongJae Park wrote: > Hi Vlastimil, > > On Mon, 17 Apr 2023 13:05:40 +0200 Vlastimil Babka <vbabka@suse.cz> wrote: > > > On 4/15/23 05:31, SeongJae Park wrote: > > > The SLAB_TYPESAFE_BY_RCU example code snippet is having not tiny RCU > > > > Since "tiny RCU" means something quite specific in the RCU world, it can be > > confusing to read it in this sense. We could say e.g. "... snippet uses a > > single RCU read-side critical section for retries"? > > Looks much better, thank you for this suggestion! > > > > > > read-side critical section. 'Documentation/RCU/rculist_nulls.rst' has > > > similar example code snippet, and commit da82af04352b ("doc: Update and > > > wordsmith rculist_nulls.rst") has broken it. > > > > "has broken it" has quite different meaning than "has broken it up" :) I > > guess we could just add the "up", unless someone has an even better wording. > > Good point, thank you for your suggestion! > > I will apply above suggestion on the next spin. For the last one, perhaps changing the tense would have more clarity: similar example code snippet, and commit da82af04352b ("doc: Update and wordsmith rculist_nulls.rst") broke it up.
On Mon, 17 Apr 2023 18:53:24 +0100 Matthew Wilcox <willy@infradead.org> wrote: > On Mon, Apr 17, 2023 at 05:26:57PM +0000, SeongJae Park wrote: > > Hi Vlastimil, > > > > On Mon, 17 Apr 2023 13:05:40 +0200 Vlastimil Babka <vbabka@suse.cz> wrote: > > > > > On 4/15/23 05:31, SeongJae Park wrote: > > > > The SLAB_TYPESAFE_BY_RCU example code snippet is having not tiny RCU > > > > > > Since "tiny RCU" means something quite specific in the RCU world, it can be > > > confusing to read it in this sense. We could say e.g. "... snippet uses a > > > single RCU read-side critical section for retries"? > > > > Looks much better, thank you for this suggestion! > > > > > > > > > read-side critical section. 'Documentation/RCU/rculist_nulls.rst' has > > > > similar example code snippet, and commit da82af04352b ("doc: Update and > > > > wordsmith rculist_nulls.rst") has broken it. > > > > > > "has broken it" has quite different meaning than "has broken it up" :) I > > > guess we could just add the "up", unless someone has an even better wording. > > > > Good point, thank you for your suggestion! > > > > I will apply above suggestion on the next spin. > > For the last one, perhaps changing the tense would have more clarity: > > similar example code snippet, and commit da82af04352b ("doc: Update and > wordsmith rculist_nulls.rst") broke it up. Thank you for this suggestion, Matthew! Will send a new version. Thanks, SJ
On Mon, Apr 17, 2023 at 07:01:29PM +0000, SeongJae Park wrote:
> Thank you for this suggestion, Matthew! Will send a new version.
Please wait 24 hours between sending new versions. Give discussion
some time to happen.
diff --git a/include/linux/slab.h b/include/linux/slab.h index b18e56c6f06c..6acf1b7c6551 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -53,16 +53,18 @@ * stays valid, the trick to using this is relying on an independent * object validation pass. Something like: * + * begin: * rcu_read_lock(); - * again: * obj = lockless_lookup(key); * if (obj) { * if (!try_get_ref(obj)) // might fail for free objects - * goto again; + * rcu_read_unlock(); + * goto begin; * * if (obj->key != key) { // not the object we expected * put_ref(obj); - * goto again; + * rcu_read_unlock(); + * goto begin; * } * } * rcu_read_unlock();