All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zqiang" <qiang.zhang@linux.dev>
To: paulmck@kernel.org
Cc: frederic@kernel.org, neeraj.upadhyay@kernel.org,
	joelagnelf@nvidia.com, urezki@gmail.com, boqun@kernel.org,
	rcu@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rcutorture: Use __set_current_state() set task state in rcu_nocb_toggle()
Date: Tue, 07 Jul 2026 13:15:10 +0000	[thread overview]
Message-ID: <490e998c483920e9e7bd796b00a337bcd11aa129@linux.dev> (raw)
In-Reply-To: <c826b59e-993f-4ff5-ac1a-6898bfaf05cc@paulmck-laptop>

> 
> On Thu, Jul 02, 2026 at 06:11:25PM +0800, Zqiang wrote:
> 
> > 
> > In the rcu_nocb_toggle(), the schedule_hrtimeout() is called after the
> >  state assignment with no condition check. the release-acquire pair from
> >  raw_spin_unlock/lock(&cpu_base->lock), guarantee that task->__state is
> >  visible to the hrtimer callback:
> >  
> >  CPU0 CPU1
> >  __set_current_state(TASK_INTERRUPTIBLE)
> >  ->WRITE_ONCE(task->__state, TASK_INTERRUPTIBLE)
> >  schedule_hrtimeout
> >  ->hrtimer_sleeper_start_expires()
> >  ->raw_spin_lock_irqsave(&cpu_base->lock)
> >  ....
> >  ->raw_spin_unlock_irqrestore(&cpu_base->lock)
> >  
> >  hard-irq:
> >  raw_spin_lock_irqsave(&cpu_base->lock)
> >  __hrtimer_run_queues
> >  ->__run_hrtimer
> >  ->raw_spin_unlock_irqrestore(&cpu_base->lock)
> >  ->fn(timer)
> >  ->hrtimer_wakeup
> >  ->wake_up_process
> >  ->try_to_wake_up
> >  ->READ task->__state
> >  
> >  This commit therefore use the __set_current_state() to replace the
> >  set_current_state() in rcu_nocb_toggle().
> >  
> >  Signed-off-by: Zqiang <qiang.zhang@linux.dev>
> > 
> This looks correct, and either drops an smp_mb() or converts an
> xchg() to a WRITE_ONCE(), which does decrease overhead. Except that
> rcu_nocb_toggle() is invoked very infrequently and has high overhead
> that I would expect to lose this overhead decrease in the noise. And it
> forces those reading the code to go figure out what is different between
> set_current_state() and __set_current_state().
> 
> So I am not convinced to take this patch. But am I missing something here?

Nothing was missed, only from memory ordering perspective,
using set_current_state() is unnecessary. 
furthermore, in RCU tasks, we used the following code:

__set_current_state(TASK_IDLE);  // in this we use __set_current_state()
schedule_hrtimeout_range(&exp, jiffies_to_nsecs(HZ / 2), HRTIMER_MODE_REL_HARD);

Or perhaps we could also add a comment something like this(kernel/time/sleep_timeout.c):

/*
 * __set_current_state() can be used in schedule_timeout_*() functions, because
 * schedule_timeout() calls schedule() unconditionally.
 */


Thanks
Zqiang


> 
>  Thanx, Paul
> 
> > 
> > ---
> >  kernel/rcu/rcutorture.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >  
> >  diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> >  index b1bab59efde5..a0e6901e0f90 100644
> >  --- a/kernel/rcu/rcutorture.c
> >  +++ b/kernel/rcu/rcutorture.c
> >  @@ -2947,7 +2947,7 @@ static int rcu_nocb_toggle(void *arg)
> >  atomic_long_inc(&n_nocb_deoffload);
> >  }
> >  toggle_delay = torture_random(&rand) % toggle_fuzz + toggle_interval;
> >  - set_current_state(TASK_INTERRUPTIBLE);
> >  + __set_current_state(TASK_INTERRUPTIBLE);
> >  schedule_hrtimeout(&toggle_delay, HRTIMER_MODE_REL);
> >  if (stutter_wait("rcu_nocb_toggle"))
> >  sched_set_normal(current, oldnice);
> >  -- 
> >  2.17.1
> >
>

  reply	other threads:[~2026-07-07 13:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02 10:11 [PATCH] rcutorture: Use __set_current_state() set task state in rcu_nocb_toggle() Zqiang
2026-07-06 18:48 ` Paul E. McKenney
2026-07-07 13:15   ` Zqiang [this message]
2026-07-07 16:44     ` Paul E. McKenney
2026-07-09 12:05       ` Zqiang
2026-07-07 15:36   ` Alan Huang

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=490e998c483920e9e7bd796b00a337bcd11aa129@linux.dev \
    --to=qiang.zhang@linux.dev \
    --cc=boqun@kernel.org \
    --cc=frederic@kernel.org \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neeraj.upadhyay@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=urezki@gmail.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.