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;
From:   "Zhang, Qiang1" <qiang1.zhang@intel.com>
To:     "paulmck@kernel.org" <paulmck@kernel.org>
CC:     Uladzislau Rezki <urezki@gmail.com>,
        "frederic@kernel.org" <frederic@kernel.org>,
        "joel@joelfernandes.org" <joel@joelfernandes.org>,
        "qiang.zhang1211@gmail.com" <qiang.zhang1211@gmail.com>,
        "rcu@vger.kernel.org" <rcu@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2] rcu/kvfree: Prevents cache growing when the
 backoff_page_cache_fill is set
Thread-Topic: [PATCH v2] rcu/kvfree: Prevents cache growing when the
 backoff_page_cache_fill is set
Thread-Index: AQHZaBxqLyldFWH+MUeQ1f1h2hb9AK8dsuCAgADdb4CAAFfuMIAAEHaAgAATPzCAAPB4AIAArT7A
Date:   Sat, 8 Apr 2023 01:56:40 +0000
Message-ID: <PH0PR11MB5880D0D946C20C4DEE3AEF99DA979@PH0PR11MB5880.namprd11.prod.outlook.com>
References: <20230406001238.647536-1-qiang1.zhang@intel.com>
 <ZC5MoREk30MIt79u@pc636>
 <8da4b48a-820c-461f-9dc0-a5afaf335177@paulmck-laptop>
 <PH0PR11MB58809B44F396B7C074BDC704DA919@PH0PR11MB5880.namprd11.prod.outlook.com>
 <9427c261-0395-4e03-8f93-2e0588fadd1f@paulmck-laptop>
 <MW5PR11MB5858999E104C21754DEB40F3DA969@MW5PR11MB5858.namprd11.prod.outlook.com>
 <c0fed568-db45-4302-b204-b4f707bba140@paulmck-laptop>
In-Reply-To: <c0fed568-db45-4302-b204-b4f707bba140@paulmck-laptop>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?xBjpUFHAYklgrB06L6Gk73GcLMFOGz/OZfJP/J7Kk0eiS36XGD8Ycy9ZC3p5?=
 =?us-ascii?Q?ohKm2lZG06l1DaAPszPxZMT69e6fRxvWtZITfukc9hmq4oM5RLf8q6myzF3e?=
 =?us-ascii?Q?p+0hyCcFZHsp0EOr1S3AbQbdZSmXIToSjzdS3EGjw/ZsiL5TUNHcuSlc68y8?=
 =?us-ascii?Q?TJFXUaYcNOUzX15CXfkUHwr7Q19q9QpUS3md7RRvPYTVXM/UfM69gZ8BhN9u?=
 =?us-ascii?Q?ulDLBeyVtTMHAlB8JVnAePxNM/AVU61uJ53BYl1hNNSg90T5cZIdndi09O/B?=
 =?us-ascii?Q?PucHD1KBBAnqAJQQOKwv0FLIAb5SaxjZiQnujwfdhtJkyfmkeNJJAU1tIT3R?=
 =?us-ascii?Q?gtSP3I1Q3a73dIxJnMLzxh0X24TROZAiC38RdWzHgpEM1Sc+0bbn/WO1n92j?=
 =?us-ascii?Q?TFBueqbtDxnCU4BmhlR2g3uyunC3YCeAhwZHugCfxwZ1jACveheqvscbQ9I0?=
 =?us-ascii?Q?+sF5MOXdVX3COttQlWbttvlx7KCBRgJCAB6ixuCDQv2VrPVbY/4MLtjBq8by?=
 =?us-ascii?Q?XJKLLjqwn5yMPWOCOP2n73dmwkBaTbCb7Q6GwSDGF+U8UvyYB17P/Jxi1Kyp?=
 =?us-ascii?Q?UOcQZ39u1w8nit3DKqkCdqs0Up/NJfGsTj0+lKlZSWVII8V5ItPyc1CFNGe1?=
 =?us-ascii?Q?NZV0UgpU/1mEmPyjED/v7YwO8O8UjKcFU7ql/+kxy52i8nyAdQtOCO8X/+UK?=
 =?us-ascii?Q?d3P4l9fCXpYRULkw2Ah5nbJb1/c0rZ3DNQeaar5HuFZi7uwSfMJuoAXqszc4?=
 =?us-ascii?Q?MW22MQ2gFC6XxlSRdXueZjR8rLzF15QroYwgyrttz4WMJoDUxA4Ca9GjOMSl?=
 =?us-ascii?Q?0TZshlKmKJ7tiNSSfJ8NGmpdh6Mh7IyUu7+CGMZzhncdDFE0hGAA+sqIBWs7?=
 =?us-ascii?Q?dVMbpNDyO8SjExtFc3hS9S5shfHDCyGjEijS3+YAfq6bf+xGF6B4KYe7Yd2l?=
 =?us-ascii?Q?kl9a6IyHhkekw7OlGM3c0oF7x8LT4GPEbr4l/lB8H5fmIjgYkCCJSf22BITf?=
 =?us-ascii?Q?eXv0Xu7REfbhmPr+FETO/v9MxKvT5sfSE3bTRuYWsElYbkH4hJ2W033Bux8e?=
 =?us-ascii?Q?Ja1h6SKMrrEuy9xUM4qWCpAJN/K2FRrJBMM3bIkiVFZhHK/wGgB+eonepmqG?=
 =?us-ascii?Q?xgqLPfkWFjb/p+/Fm49PD8NKL3IsB/xyoJhSUBs/5UyNb5IVta44uaGgKj5Q?=
 =?us-ascii?Q?nF6idmqgY45zVmu91DVSpxATluJn3swbx9khyFZ4Fgly6hMzhm/cT8qkIDwi?=
 =?us-ascii?Q?1QX/aw6Jxdoa0mOQmxCJwK5+J3rPU6h1XPkBps7rX7argRlmqwlXk8ttUuJh?=
 =?us-ascii?Q?aYDRs1imF0HFTXgJdTjxXbS95/BslkwPq5m+u6skcRJ3T+Ltvg30mAeiexpe?=
 =?us-ascii?Q?hgLqJ0zg8zPUwQKEwG0kJIEFnQlNHzbMp7OIEA1W4cOHo9aIndG/+g8gkXCr?=
 =?us-ascii?Q?Xc21lMcD3g9+1i75nVhiM0Cz8w+dpoS+JyxlpOV7A+yjXof/upuEEVgCjsv9?=
 =?us-ascii?Q?dINizkkRua5eiLRHyqh6bIruMOGs0xhoSHgEULF5nHAnwVN/Xg076iuylz0p?=
 =?us-ascii?Q?SXgHfjoPXxqC1puG7MZrXBQLOgsDtkKN9JHjjBqp?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5880.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 04dce5d7-642c-4d19-c7c3-08db37d47eac
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2023 01:56:40.0824
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1Pd8PHVj8ahI37oZIqSGpz5XjW4Wf8exsRhqcnNcVae5YkXq1rB3tAD123G42j6elO3Stvy+D+9kwSNjfX9Tew==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5117
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,
        SPF_NONE 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Apr 07, 2023 at 01:26:39AM +0000, Zhang, Qiang1 wrote:
> > >>On Thu, Apr 06, 2023 at 06:37:53AM +0200, Uladzislau Rezki wrote:
> > > On Thu, Apr 06, 2023 at 08:12:38AM +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 bno=
de
> > > > 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 pa=
ge
> > > > cache growing.
> > > >=20
> > > > Signed-off-by: Zqiang <qiang1.zhang@intel.com>
> > > > ---
> > > >  kernel/rcu/tree.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >=20
> > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > > index 9cc0a7766fd2..f25430ae1936 100644
> > > > --- a/kernel/rcu/tree.c
> > > > +++ b/kernel/rcu/tree.c
> > > > @@ -2907,6 +2907,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;
> > > >  	// Check the limit.
> > > >  	if (krcp->nr_bkv_objs >=3D rcu_min_cached_objs)
> > > >  		return false;
> > > > --=20
> > > > 2.32.0
> > > >
> > > Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> > >
> > >Thank you both!
> > >
> > >One question, though.  Might it be better to instead modify the "for"
> > >loop in fill_page_cache_func() to start at krcp->nr_bkv_objs instead
> > >of starting at zero?  That way, we still provide a single page under
> > >low-memory conditions, but provide rcu_min_cached_objs of them if memo=
ry
> > >is plentiful.
> > >
> > >Alternatively, if we really don't want to allow any pages at all under
> > >low-memory conditions, shouldn't the fill_page_cache_func() set nr_pag=
es
> > >to zero (instead of the current 1) when the krcp->backoff_page_cache_f=
ill
> > >flag is set? =20
> >=20
> > Hi, Paul
> >=20
> > If the krcp->backoff_page_cache_fill is true, the put_cached_bnode () r=
eturn false,
> > the allocated single page will also be freed in fill_page_cache_func().
> >=20
> > or it would be better not to allocate under memory pressure.
> >
> >That was my thought.  ;-)
> >
> > How about like this?
> >=20
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 9cc0a7766fd2..94aedbc3da36 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -2907,6 +2907,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;
> >         // Check the limit.
> >         if (krcp->nr_bkv_objs >=3D rcu_min_cached_objs)
> >                 return false;
> > @@ -3220,7 +3222,7 @@ static void fill_page_cache_func(struct work_stru=
ct *work)
> >         int i;
> >=20
> >         nr_pages =3D atomic_read(&krcp->backoff_page_cache_fill) ?
> > -               1 : rcu_min_cached_objs;
> > +               0 : rcu_min_cached_objs;
> >=20
> >         for (i =3D 0; i < nr_pages; i++) {
> >
> >The other question is why this loop does not allow for any pages
> >that might already be allocated, thus perhaps looking like this:
> >
> >		for (i =3D krcp->nr_bkv_objs; i < nr_pages; i++) {
> >
> >Or do we somehow know that krcp->nr_bkv_objs is equal to zero?  (I am no=
t
> >seeing this, but I do feel the need to ask.)
>=20
>=20
> The fill_page_cache_func() is triggered when we invoke get_cached_bnode()=
 return NULL,
> this also means that krcp->nr_bkv_objs is equal to zero.=20
> But if can_alloc is set,  we will unlock krcp0->lock and allocated single=
 page,  after that
> we will reacquire krcp1 and lock,  but the krcp1 at this time may be diff=
erent from the
> previous krcp0,  if !bnode is true, also trigger work to invoke fill_page=
_cache_func(),  but
> maybe the krcp1-> nr_bkv_objs is not equal to zero.
>
>OK.  Given all of these good points, what would be a good patch for
>this issue?  ;-)

Is it possible to keep the filling of the page always on the correct krcp?

--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3303,7 +3303,7 @@ add_ptr_to_bulk_krc_lock(struct kfree_rcu_cpu **krcp,
                        // scenarios.
                        bnode =3D (struct kvfree_rcu_bulk_data *)
                                __get_free_page(GFP_KERNEL | __GFP_NORETRY =
| __GFP_NOMEMALLOC | __GFP_NOWARN);
-                       *krcp =3D krc_this_cpu_lock(flags);
+                       raw_spin_lock_irqsave(&(*krcp)->lock, *flags);
                }

                if (!bnode)


thoughts?

Thanks
Zqiang


>
>							Thanx, Paul
>
> Thanks
> Zqiang
>=20
>=20
> >
> >							Thanx, Paul
> >
> >                 bnode =3D (struct kvfree_rcu_bulk_data *)
> >=20
> > Thanks
> > Zqiang
> >=20
> > >This would likely mean also breaking out of that loop if
> > >krcp->backoff_page_cache_fill was set in the meantime (which happens
> > >implicitly with Zqiang's patch).
> > >
> > >Or am I missing something subtle here?
> > >
> > >							Thanx, Paul