Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp4761833rwl; Mon, 10 Apr 2023 16:48:53 -0700 (PDT) X-Google-Smtp-Source: AKy350bFIIc5O98JwwaDJNdLO7xwPgcQ4wAn1o7zF1vi0yn1FMCDDaNZQVV6XcXnPDxBIGimbR9C X-Received: by 2002:a05:6a20:33a8:b0:e3:8710:6848 with SMTP id f40-20020a056a2033a800b000e387106848mr8013297pzd.41.1681170533022; Mon, 10 Apr 2023 16:48:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681170533; cv=none; d=google.com; s=arc-20160816; b=ghMJRrnUGaOz3j/7uaNkVc02H73JDxuQsb+jydmGqMlQZV4f6ZVwaFUanF87Prr7Rq LGq+ZpeZpS0Rx1WpXVmFFtJWjhXR2TlQYL74NJKiZ0UwXuEZKegoPQEYyjPbke2Y/BWT 0B0O/fMZWfBNEIVH6LK5SpE+cnwFbDxwies2PvdOxKdNjoCrL0O8cF8/lHS5B4s0P9Kb PeR0Oe1ig287X5GrYOV9WgC0wHrNUeqnm1dhCfPPiBTi+0l123/12OJOpAjDUjpNz6dc IoGNwO9L2R3VJkPcc960ivBfktgTi2GMwDvqSbNl9oiHKgso0xaVrrMbJH5Jh5WYlUub bLfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=opAO4NcMdn9HCh287aRQhahhKo0xt05hME4jaA267gw=; b=uImwjclvB5JogCwqZ+L1pVIjJnICN58la4rjuvMlj+vOQ0bLFU0Fq4NJ8NXLBoPNrX u5+LnDUSAn7+W8EGB6d0iOmdEB6aXCwMdR9UYY/gKXb/bnKTdWTutZPmvB6RUm6CzLf3 Cz7Ovop1GH5Y9oSp9rnZ5OKqL/Lu9B9hs0vq8qUMDg7gjZEKHulAJp6629a5ZCqC7LeG go9PggUnUNiw5gdHY3w+itA769bIZ4wYqEDlPU+Bu/KVCPvg77opXpCbZyp7YmFClEiq q57yemr63UHHbIMrLqxOS5UeJemZASymWXSGHnIxk5dqOzv+2FeK5QQbyb7bsCFsTXAa sizg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=gl6yNMDA; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h123-20020a636c81000000b00507249cdbb4si6791524pgc.296.2023.04.10.16.48.41; Mon, 10 Apr 2023 16:48:52 -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=gl6yNMDA; 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 S229964AbjDJXfC (ORCPT + 99 others); Mon, 10 Apr 2023 19:35:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229591AbjDJXfB (ORCPT ); Mon, 10 Apr 2023 19:35:01 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7DC6185; Mon, 10 Apr 2023 16:35:00 -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 7220761982; Mon, 10 Apr 2023 23:35:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAD12C433EF; Mon, 10 Apr 2023 23:34:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681169699; bh=FCDVQiK/WUm1WPDlCxcSnDSPyEfQ3zafLdbSMLvTnGM=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=gl6yNMDArz7FY/iRC8A/Yq56qpvmFGFGv8QAAldCrSnlezdgBt7Q4y31FGgMEuo77 aUgxjxVLgU7wTRntn5ockwsYf0zrGowym6qBvZR59Pq5vRSGntecRuhqlBGMrO7UE2 pEIEoHIZqIMHfX8XjIztjHR1btuDNK5GukDlNkiGFHfAFrBTFuOuA00DSAAGJwc9my 4kjnb/4ZLkDpOcUGXcOqqLliM54hjNYuG7YOFJpJfs/LdzyvKE/kQAc8CTzoeQILyY CE1VSejtXrkVgg2zSG91CpM4W6ljKGYFcwYIW4LWSu4MTnM9gFUczeGAmXC9zKZGm3 4lYLMm06si4DA== Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id 5E9871540478; Mon, 10 Apr 2023 16:34:59 -0700 (PDT) Date: Mon, 10 Apr 2023 16:34:59 -0700 From: "Paul E. McKenney" To: Zqiang Cc: urezki@gmail.com, frederic@kernel.org, joel@joelfernandes.org, qiang.zhang1211@gmail.com, rcu@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] rcu/kvfree: Prevents cache growing when the backoff_page_cache_fill is set Message-ID: Reply-To: paulmck@kernel.org References: <20230408142517.800549-1-qiang1.zhang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230408142517.800549-1-qiang1.zhang@intel.com> X-Spam-Status: No, score=-5.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable 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: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 08, 2023 at 10:25:17PM +0800, Zqiang wrote: > Currently, in kfree_rcu_shrink_scan(), the drain_page_cache() is > executed before kfree_rcu_monitor() to drain page cache, if the bnode > structure's->gp_snap has done, the kvfree_rcu_bulk() will fill the > page cache again in kfree_rcu_monitor(), this commit add a check > for krcp structure's->backoff_page_cache_fill in put_cached_bnode(), > if the krcp structure's->backoff_page_cache_fill is set, prevent page > cache growing and disable allocated page in fill_page_cache_func(). > > Signed-off-by: Zqiang Much improved! But still some questions below... Thanx, Paul > --- > kernel/rcu/tree.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index cc34d13be181..9d9d3772cc45 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -2908,6 +2908,8 @@ static inline bool > put_cached_bnode(struct kfree_rcu_cpu *krcp, > struct kvfree_rcu_bulk_data *bnode) > { > + if (atomic_read(&krcp->backoff_page_cache_fill)) > + return false; This will mean that under low-memory conditions, we will keep zero pages in ->bkvcache. All attempts to put something there will fail. This is probably not an issue for structures containing an rcu_head that are passed to kfree_rcu(p, field), but doesn't this mean that kfree_rcu_mightsleep() unconditionally invokes synchronize_rcu()? This could seriously slow up freeing under low-memory conditions, which might exacerbate the low-memory conditions. Is this really what we want? Zero cached rather than just fewer cached? > // Check the limit. > if (krcp->nr_bkv_objs >= rcu_min_cached_objs) > return false; > @@ -3221,7 +3223,7 @@ static void fill_page_cache_func(struct work_struct *work) > int i; > > nr_pages = atomic_read(&krcp->backoff_page_cache_fill) ? > - 1 : rcu_min_cached_objs; > + 0 : rcu_min_cached_objs; > > for (i = 0; i < nr_pages; i++) { I am still confused as to why we start "i" at zero rather than at ->nr_bkv_objs. What am I missing here? > bnode = (struct kvfree_rcu_bulk_data *) > -- > 2.32.0 >