From: Peter Zijlstra <peterz@infradead.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC tip/core/rcu] Avoid resched_cpu() when rescheduling the current CPU
Date: Mon, 30 Jul 2018 18:42:47 +0200 [thread overview]
Message-ID: <20180730164247.GN2494@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20180730145933.GX24813@linux.vnet.ibm.com>
On Mon, Jul 30, 2018 at 07:59:33AM -0700, Paul E. McKenney wrote:
> > Something that might be more in line with
> > resched_curr(smp_processor_id()) would be:
> >
> > preempt_disable();
> > if (!test_tsk_need_resched(current)) {
> > set_tsk_need_resched(current);
> > set_preempt_need_resched();
> > }
> > preempt_enable();
> >
> > Where the preempt_enable() could of course instantly trigger the
> > reschedule if it was the outer most one.
>
> Ah. So should I use resched_curr() from rcu_check_callbacks(), which
> is invoked from the scheduling-clock interrupt? Right now I have calls
> to set_tsk_need_resched() and set_preempt_need_resched().
>
> > > @@ -2674,10 +2675,12 @@ static __latent_entropy void rcu_process_callbacks(struct softirq_action *unused
> >
> > > - resched_cpu(rdp->cpu); /* Provoke future context switch. */
> >
> > > + set_tsk_need_resched(current);
> > > + set_preempt_need_resched();
> >
> > That's not obviously correct. rdp->cpu had better be smp_processor_id().
>
> At the beginning of the function, we have:
>
> struct rcu_data *rdp = raw_cpu_ptr(&rcu_data);
>
> And this is in a softirq handler, so we are OK.
Agreed.
> > > @@ -672,7 +672,8 @@ static void sync_rcu_exp_handler(void *unused)
> > > rcu_report_exp_rdp(rdp);
> > > } else {
> > > rdp->deferred_qs = true;
> > > - resched_cpu(rdp->cpu);
> > > + set_tsk_need_resched(t);
> > > + set_preempt_need_resched();
> >
> > That only works if @t == current.
>
> At the beginning of the function, we have:
>
> struct task_struct *t = current;
>
> So we should be OK.
Ah, the scheduler and locking code typically use to call that curr, to
be more explicit that it is the current task.
> Should I be instead using resched_curr() on some or all of these?
If, as it seems is the case, they are all targeting the current cpu and
have (soft) interrupts disabled, then what you propose is indeed fine.
next prev parent reply other threads:[~2018-07-30 16:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-27 15:49 [PATCH RFC tip/core/rcu] Avoid resched_cpu() when rescheduling the current CPU Paul E. McKenney
2018-07-30 9:25 ` Peter Zijlstra
2018-07-30 14:59 ` Paul E. McKenney
2018-07-30 16:42 ` Peter Zijlstra [this message]
2018-07-30 17:14 ` Paul E. McKenney
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=20180730164247.GN2494@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox