From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, mingo@redhat.com,
tglx@linutronix.de
Subject: Re: [PATCH] time/tick-broadcast: Fix tick_broadcast_offline() lockdep complaint
Date: Mon, 24 Jun 2019 16:44:22 -0700 [thread overview]
Message-ID: <20190624234422.GP26519@linux.ibm.com> (raw)
In-Reply-To: <20190624231222.GA17497@lerouge>
On Tue, Jun 25, 2019 at 01:12:23AM +0200, Frederic Weisbecker wrote:
> On Fri, Jun 21, 2019 at 04:46:02PM -0700, Paul E. McKenney wrote:
> > @@ -3097,13 +3126,21 @@ static void sched_tick_remote(struct work_struct *work)
> > /*
> > * Run the remote tick once per second (1Hz). This arbitrary
> > * frequency is large enough to avoid overload but short enough
> > - * to keep scheduler internal stats reasonably up to date.
> > + * to keep scheduler internal stats reasonably up to date. But
> > + * first update state to reflect hotplug activity if required.
> > */
> > + os = atomic_read(&twork->state);
> > + if (os) {
> > + WARN_ON_ONCE(os != TICK_SCHED_REMOTE_OFFLINING);
> > + if (atomic_inc_not_zero(&twork->state))
> > + return;
>
> Using inc makes me a bit nervous here. If we do so, we should somewhow
> make sure that we never exceed a value higher than TICK_SCHED_REMOTE_OFFLINE
> by accident.
>
> atomic_xchg() is probably a bit costlier but also safer as it allows
> us to check both the old and the new value. That path shouldn't be critically fast
> after all.
It would need to be cmpxchg() to avoid messing with the state if
the state were somehow TICK_SCHED_REMOTE_RUNNING, right?
> > + }
> > queue_delayed_work(system_unbound_wq, dwork, HZ);
> > }
> >
> > static void sched_tick_start(int cpu)
> > {
> > + int os;
> > struct tick_work *twork;
> >
> > if (housekeeping_cpu(cpu, HK_FLAG_TICK))
> > @@ -3112,15 +3149,20 @@ static void sched_tick_start(int cpu)
> > WARN_ON_ONCE(!tick_work_cpu);
> >
> > twork = per_cpu_ptr(tick_work_cpu, cpu);
> > - twork->cpu = cpu;
> > - INIT_DELAYED_WORK(&twork->work, sched_tick_remote);
> > - queue_delayed_work(system_unbound_wq, &twork->work, HZ);
> > + os = atomic_xchg(&twork->state, TICK_SCHED_REMOTE_RUNNING);
> > + WARN_ON_ONCE(os == TICK_SCHED_REMOTE_RUNNING);
>
> See if we use atomic_inc(), we would need to also WARN(os > TICK_SCHED_REMOTE_OFFLINE).
How about if I put that WARN() between the atomic_inc_not_zero() and
the return, presumably also adding braces?
Thanx, Paul
> > + if (os == TICK_SCHED_REMOTE_OFFLINE) {
> > + twork->cpu = cpu;
> > + INIT_DELAYED_WORK(&twork->work, sched_tick_remote);
> > + queue_delayed_work(system_unbound_wq, &twork->work, HZ);
> > + }
> > }
>
> Thanks.
>
next prev parent reply other threads:[~2019-06-24 23:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-19 18:19 [PATCH] time/tick-broadcast: Fix tick_broadcast_offline() lockdep complaint Paul E. McKenney
2019-06-20 12:10 ` Peter Zijlstra
2019-06-20 16:01 ` Paul E. McKenney
2019-06-20 21:10 ` Peter Zijlstra
2019-06-20 22:13 ` Paul E. McKenney
2019-06-21 10:55 ` Peter Zijlstra
2019-06-21 12:16 ` Paul E. McKenney
2019-06-21 12:29 ` Peter Zijlstra
2019-06-21 13:34 ` Paul E. McKenney
2019-06-21 17:41 ` Paul E. McKenney
2019-06-21 17:50 ` Paul E. McKenney
2019-06-21 23:46 ` Paul E. McKenney
2019-06-24 23:12 ` Frederic Weisbecker
2019-06-24 23:44 ` Paul E. McKenney [this message]
2019-06-25 0:43 ` Frederic Weisbecker
2019-06-25 2:05 ` Paul E. McKenney
2019-06-25 7:51 ` Peter Zijlstra
2019-06-25 12:25 ` Frederic Weisbecker
2019-06-25 13:54 ` Paul E. McKenney
2019-06-25 14:05 ` Peter Zijlstra
2019-06-25 14:16 ` Paul E. McKenney
2019-06-25 16:20 ` Frederic Weisbecker
2019-06-25 16:52 ` Paul E. McKenney
2019-06-28 7:37 ` Peter Zijlstra
2019-06-28 12:17 ` Paul E. McKenney
2019-07-25 16:14 ` [tip:sched/core] " tip-bot for Paul E. McKenney
-- strict thread matches above, loose matches on Subject: below --
2019-05-27 14:39 [PATCH] " Paul E. McKenney
2019-05-28 20:07 ` Thomas Gleixner
2019-05-29 18:19 ` Paul E. McKenney
2019-05-30 12:58 ` Paul E. McKenney
2019-05-31 1:36 ` Frederic Weisbecker
2019-05-31 13:43 ` 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=20190624234422.GP26519@linux.ibm.com \
--to=paulmck@linux.ibm.com \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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.