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 X-Spam-Level: X-Spam-Status: No, score=-8.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB10FC47257 for ; Mon, 4 May 2020 17:48:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 83B47206D9 for ; Mon, 4 May 2020 17:48:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZAh8Ld/j" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 83B47206D9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0A8E58E0069; Mon, 4 May 2020 13:48:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05A118E0058; Mon, 4 May 2020 13:48:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB22C8E0069; Mon, 4 May 2020 13:48:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by kanga.kvack.org (Postfix) with ESMTP id D56198E0058 for ; Mon, 4 May 2020 13:48:27 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 96A35180AD80F for ; Mon, 4 May 2020 17:48:27 +0000 (UTC) X-FDA: 76779771054.07.push87_49d527ab89018 X-HE-Tag: push87_49d527ab89018 X-Filterd-Recvd-Size: 7619 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 17:48:27 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id b26so745195lfa.5 for ; Mon, 04 May 2020 10:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ufpIeFmcKaIEVY6FRQ1/+O0Pn/Xjsjbz3pEhyns+6jw=; b=ZAh8Ld/jlx1jmmCPIeCJ2rRIos8a28KH8H/Hrer+1tyMica5znVSMEwwO+OBBIC118 AmsTqZyFLfNTy1AOmddTyJ+moXb+7dL8miYOHqkVf/52UC3Xa6oEDUKGEBwhpo5ZC9a+ VDHRMAsK2QUnNIQyxPuesRC6DS7l96p96vDP/gIHTxlljh3CfX+p8hzv8mE0Dp8aH+pi 3vJfOmSQWMpvetNst/kEbw8cHuHV9Zh6DR/lMAZhmyh+pyA8Y7Sr1oeBsLSX5QSoUIN7 8XLvymEJggFvYiMN7t3D4X/1ldL3MiZIE4Zl9Di/a5FvBHfHaNvR3zbedERWypJmyrQ0 ZntA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ufpIeFmcKaIEVY6FRQ1/+O0Pn/Xjsjbz3pEhyns+6jw=; b=JeMd90SA24tIkQRQtHCGuap1CTJ2fRTXP4cM9TKyjf8SP+XYuf8xMFwh2EAblNcU6m AP2trKlu6s4g36sT0emDXqOrPeJQkMkvZ77zzJ6gC/0uBHBpCBHk0lXIS1y5Uqxpw+Al mLfnUnPCLEl/MhXtGsjecfZQEIZyNTy+OVmGwRoe9In1KWH0Yx0OJjd7iQuYFf0TWOPd JAuh5OX8xMAqouik+pC/XQWlOuKP0p5BsIFns+h9ZQgQW+hlfkUlRriT8sQU2Gz6y0ob NWayLSSUVr1Dfy+zmjQxGT/hE8MTY7Yga47CDwVGlSxPDv0UW+zgEPf5D4UZJW1rmvlP J+sQ== X-Gm-Message-State: AGi0PuYokT09aI6wmnMT7cEzbBqs9J8MfrjOPrFk8bRa58y075UbW+xw OqYqYxsJw84lODXVJJtyP6yfQHx2SVG8rA== X-Google-Smtp-Source: APiQypIn9k+BgZSHofdoK+xEoluwCmPe+zJr6r5AGYebAphv3YmqBkABK1xXyqd/fIQaBVPC/Bow8w== X-Received: by 2002:ac2:53af:: with SMTP id j15mr251493lfh.191.1588614505736; Mon, 04 May 2020 10:48:25 -0700 (PDT) Received: from pc636 (h5ef52e31.seluork.dyn.perspektivbredband.net. [94.245.46.49]) by smtp.gmail.com with ESMTPSA id n7sm11138476ljj.72.2020.05.04.10.48.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2020 10:48:25 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 4 May 2020 19:48:22 +0200 To: "Paul E. McKenney" Cc: Uladzislau Rezki , LKML , linux-mm@kvack.org, Andrew Morton , "Theodore Y . Ts'o" , Matthew Wilcox , Joel Fernandes , RCU , Oleksiy Avramchenko Subject: Re: [PATCH 09/24] rcu/tree: cache specified number of objects Message-ID: <20200504174822.GA20446@pc636> References: <20200428205903.61704-1-urezki@gmail.com> <20200428205903.61704-10-urezki@gmail.com> <20200501212749.GD7560@paulmck-ThinkPad-P72> <20200504124323.GA17577@pc636> <20200504152437.GK2869@paulmck-ThinkPad-P72> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200504152437.GK2869@paulmck-ThinkPad-P72> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, May 04, 2020 at 08:24:37AM -0700, Paul E. McKenney wrote: > On Mon, May 04, 2020 at 02:43:23PM +0200, Uladzislau Rezki wrote: > > On Fri, May 01, 2020 at 02:27:49PM -0700, Paul E. McKenney wrote: > > > On Tue, Apr 28, 2020 at 10:58:48PM +0200, Uladzislau Rezki (Sony) wrote: > > > > Cache some extra objects per-CPU. During reclaim process > > > > some pages are cached instead of releasing by linking them > > > > into the list. Such approach provides O(1) access time to > > > > the cache. > > > > > > > > That reduces number of requests to the page allocator, also > > > > that makes it more helpful if a low memory condition occurs. > > > > > > > > A parameter reflecting the minimum allowed pages to be > > > > cached per one CPU is propagated via sysfs, it is read > > > > only, the name is "rcu_min_cached_objs". > > > > > > > > Signed-off-by: Uladzislau Rezki (Sony) > > > > --- > > > > kernel/rcu/tree.c | 64 ++++++++++++++++++++++++++++++++++++++++++++--- > > > > 1 file changed, 60 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > > > index 89e9ca3f4e3e..d8975819b1c9 100644 > > > > --- a/kernel/rcu/tree.c > > > > +++ b/kernel/rcu/tree.c > > > > @@ -178,6 +178,14 @@ module_param(gp_init_delay, int, 0444); > > > > static int gp_cleanup_delay; > > > > module_param(gp_cleanup_delay, int, 0444); > > > > > > > > +/* > > > > + * This rcu parameter is read-only, but can be write also. > > > > > > You mean that although the parameter is read-only, you see no reason > > > why it could not be converted to writeable? > > > > > I added just a note. If it is writable, then we can change the size of the > > per-CPU cache dynamically, i.e. "echo 5 > /sys/.../rcu_min_cached_objs" > > would cache 5 pages. But i do not have a strong opinion if it should be > > writable. > > > > > If it was writeable, and a given CPU had the maximum numbr of cached > > > objects, the rcu_min_cached_objs value was decreased, but that CPU never > > > saw another kfree_rcu(), would the number of cached objects change? > > > > > No. It works the way: unqueue the page from cache in the kfree_rcu(), > > whereas "rcu work" will put it back if number of objects < rcu_min_cached_objs, > > if >= will free the page. > > Just to make sure I understand... If someone writes a smaller number to > the sysfs variable, the per-CPU caches will be decreased at that point, > immediately during that sysfs write? Or are you saying something else? > This patch defines it as read-only. It defines the minimum threshold that controls number of elements in the per-CPU cache. If we decide to make it write also, then we will have full of freedom how to define its behavior, i.e. it is not defined because it is read only. > > > Presumably the list can also be accessed without holding this lock, > > > because otherwise we shouldn't need llist... > > > > > Hm... We increase the number of elements in cache, therefore it is not > > lockless. From the other hand i used llist_head to maintain the cache > > because it is single linked list, we do not need "*prev" link. Also > > we do not need to init the list. > > > > But i can change it to list_head. Please let me know if i need :) > > Hmmm... Maybe it is time for a non-atomic singly linked list? In the RCU > callback processing, the operations were open-coded, but they have been > pushed into include/linux/rcu_segcblist.h and kernel/rcu/rcu_segcblist.*. > > Maybe some non-atomic/protected/whatever macros in the llist.h file? > Or maybe just open-code the singly linked list? (Probably not the > best choice, though.) Add comments stating that the atomic properties > of the llist functions aren't neded? Something else? > In order to keep it simple i can replace llist_head by the list_head? > > The comments would be a good start. Just to take pity on people seeing > the potential for concurrency and wondering how the concurrent accesses > actually happen. ;-) > Sounds like you are kidding me :) -- Vlad Rezki