From: Uladzislau Rezki <urezki@gmail.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: "Zhang, Qiang1" <qiang1.zhang@intel.com>,
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
Date: Sat, 8 Apr 2023 10:00:21 +0200 [thread overview]
Message-ID: <ZDEfFcEhirm443xE@pc636> (raw)
In-Reply-To: <9427c261-0395-4e03-8f93-2e0588fadd1f@paulmck-laptop>
On Thu, Apr 06, 2023 at 05:04:03PM -0700, Paul E. McKenney wrote:
> On Thu, Apr 06, 2023 at 11:11:37PM +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 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.
> > > >
> > > > Signed-off-by: Zqiang <qiang1.zhang@intel.com>
> > > > ---
> > > > kernel/rcu/tree.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > 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 >= rcu_min_cached_objs)
> > > > return false;
> > > > --
> > > > 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 memory
> > >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_pages
> > >to zero (instead of the current 1) when the krcp->backoff_page_cache_fill
> > >flag is set?
> >
> > Hi, Paul
> >
> > If the krcp->backoff_page_cache_fill is true, the put_cached_bnode () return false,
> > the allocated single page will also be freed in fill_page_cache_func().
> >
> > or it would be better not to allocate under memory pressure.
>
> That was my thought. ;-)
>
> > How about like this?
> >
> > 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 >= rcu_min_cached_objs)
> > return false;
> > @@ -3220,7 +3222,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++) {
>
> 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 = krcp->nr_bkv_objs; i < nr_pages; i++) {
>
> Or do we somehow know that krcp->nr_bkv_objs is equal to zero? (I am not
> seeing this, but I do feel the need to ask.)
>
Usually we start from zero, this is when a ptr. was not added into
a bulk array, due to no memory reason for a single argument and no
cache pages anymore for double argument.
In the fill page function, the limit is checked by the put_cached_bnode() itself
so it stops prefetch once nr_bkv_objs contains desired value.
--
Uladzislau Rezki
next prev parent reply other threads:[~2023-04-08 8:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-06 0:12 [PATCH v2] rcu/kvfree: Prevents cache growing when the backoff_page_cache_fill is set Zqiang
2023-04-06 4:37 ` Uladzislau Rezki
2023-04-06 17:50 ` Paul E. McKenney
2023-04-06 23:11 ` Zhang, Qiang1
2023-04-07 0:04 ` Paul E. McKenney
2023-04-07 1:26 ` Zhang, Qiang1
2023-04-07 15:33 ` Paul E. McKenney
2023-04-08 1:56 ` Zhang, Qiang1
2023-04-08 9:04 ` Uladzislau Rezki
2023-04-08 8:00 ` Uladzislau Rezki [this message]
2023-04-12 4:18 ` Zhang, Qiang1
2023-04-12 12:36 ` Uladzislau Rezki
2023-04-12 13:17 ` Uladzislau Rezki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZDEfFcEhirm443xE@pc636 \
--to=urezki@gmail.com \
--cc=frederic@kernel.org \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=qiang.zhang1211@gmail.com \
--cc=qiang1.zhang@intel.com \
--cc=rcu@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.