All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: Harry Yoo <harry@kernel.org>
Cc: Uladzislau Rezki <urezki@gmail.com>,
	Zhan Xusheng <zhanxusheng1024@gmail.com>,
	vbabka@kernel.org, paulmck@kernel.org, qiang.zhang@linux.dev,
	akpm@linux-foundation.org, hao.li@linux.dev, cl@gentwo.org,
	rientjes@google.com, roman.gushchin@linux.dev,
	linux-mm@kvack.org, rcu@vger.kernel.org,
	linux-kernel@vger.kernel.org, zhanxusheng@xiaomi.com
Subject: Re: [PATCH 2/2] mm/slab: don't queue the page cache work under krcp->lock
Date: Mon, 9 Nov 2026 12:48:31 +0100	[thread overview]
Message-ID: <avGzD8CAgg9Hif__@milan> (raw)
In-Reply-To: <au3ELzm_s9vhs7UO@thinkstation>

On Fri, Nov 06, 2026 at 12:21:28PM +0000, Harry Yoo wrote:
> On Fri, Nov 06, 2026 at 10:35:13AM +0100, Uladzislau Rezki wrote:
> > On Wed, Oct 28, 2026 at 09:46:47PM +0800, Zhan Xusheng wrote:
> > > From: Zhan Xusheng <zhanxusheng@xiaomi.com>
> > > 
> > > run_page_cache_worker() runs under krcp->lock, from kvfree_call_rcu()
> > > callers that may hold more, such as set_cpus_allowed_force() under
> > > pi_lock, so it kicks the refill work from an hrtimer.  Under memory
> > > pressure it instead queues the work with a delay of
> > > rcutree.rcu_delay_page_cache_fill_msec, which may be 0, and a zero delay
> > > queues it at once, taking pool->lock under krcp->lock.
> > > 
> > > With the delay set to 0, calling kvfree_rcu() on vmalloc memory under
> > > pi_lock after a drop_caches makes lockdep report:
> > > 
> > >   Chain exists of:
> > >     &pool->lock --> &p->pi_lock --> krc.lock
> > > 
> > > Use the hrtimer when the delay is 0.
> > > 
> > > Fixes: d0bfa8b3c411 ("kvfree_rcu: Release a page cache under memory pressure")
> > > Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
> > > ---
> > >  mm/slab_common.c | 8 +++++++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/mm/slab_common.c b/mm/slab_common.c
> > > index 3729aa7a6156..ef5ff0a20249 100644
> > > --- a/mm/slab_common.c
> > > +++ b/mm/slab_common.c
> > > @@ -1987,7 +1987,13 @@ run_page_cache_worker(struct kfree_rcu_cpu *krcp)
> > >  
> > >  	if (rcu_scheduler_active == RCU_SCHEDULER_RUNNING &&
> > >  			!atomic_xchg(&krcp->work_in_progress, 1)) {
> > > -		if (atomic_read(&krcp->backoff_page_cache_fill)) {
> > > +		/*
> > > +		 * A zero delay would queue the work right here, under
> > > +		 * krcp->lock and possibly the caller's pi_lock, so let the
> > > +		 * hrtimer do it.
> > > +		 */
> > > +		if (atomic_read(&krcp->backoff_page_cache_fill) &&
> > > +		    rcu_delay_page_cache_fill_msec) {
> > >  			queue_delayed_work(rcu_reclaim_wq,
> > >  				&krcp->page_cache_work,
> > >  					msecs_to_jiffies(rcu_delay_page_cache_fill_msec));
> > > -- 
> > > 2.43.0
> > > 
> > > 
> > Can we just clamp this to 1 - 100 seconds interval?
> 
> You mean clamp to [1:100,000] milliseconds interval?
> 
Yes. It is now in milliseconds.

So starting with 1 - means that it can be configured at least from 1 msec
whereas 0 is forbidden. Also we can drop the extra "if condition" proposed
in the patch as it never can be zero.

--
Uladzislau Rezki


  reply	other threads:[~2026-11-09 11:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-28 13:46 [PATCH 1/2] mm/slab: restore the rcutree. prefix of the kvfree_rcu parameters Zhan Xusheng
2026-10-28 13:46 ` [PATCH 2/2] mm/slab: don't queue the page cache work under krcp->lock Zhan Xusheng
2026-11-02 14:35   ` Harry Yoo
2026-11-04  8:19     ` Vlastimil Babka (SUSE)
2026-11-06  8:00     ` Hao Li
2026-11-06 11:32     ` Hao Li
2026-11-06  9:35   ` Uladzislau Rezki
2026-11-06 12:18     ` Zhan Xusheng
2026-11-06 12:21     ` Harry Yoo
2026-11-09 11:48       ` Uladzislau Rezki [this message]
2026-11-09 13:13         ` Harry Yoo
2026-11-09 13:47           ` Uladzislau Rezki
2026-10-28 15:23 ` [PATCH 1/2] mm/slab: restore the rcutree. prefix of the kvfree_rcu parameters Harry Yoo
2026-11-02 14:33   ` Harry Yoo
2026-11-04  8:17     ` Vlastimil Babka (SUSE)
2026-11-06  7:59     ` Hao Li
2026-11-02 14:27 ` Harry Yoo (Meta)

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=avGzD8CAgg9Hif__@milan \
    --to=urezki@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@gentwo.org \
    --cc=hao.li@linux.dev \
    --cc=harry@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=paulmck@kernel.org \
    --cc=qiang.zhang@linux.dev \
    --cc=rcu@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=zhanxusheng1024@gmail.com \
    --cc=zhanxusheng@xiaomi.com \
    /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.