From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>,
Clark Williams <williams@redhat.com>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
John Kacur <jkacur@redhat.com>
Subject: Re: [RFC][PATCH tip/sched/core] sched/rt: Simplify the IPI rt balancing logic
Date: Mon, 24 Apr 2017 14:52:00 +0200 [thread overview]
Message-ID: <20170424125200.vxfmehm4tpdpeisc@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20170424084318.2d03700f@gandalf.local.home>
On Mon, Apr 24, 2017 at 08:43:18AM -0400, Steven Rostedt wrote:
> On Mon, 24 Apr 2017 10:51:54 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Fri, Apr 21, 2017 at 10:49:29PM -0400, Steven Rostedt wrote:
> > > When a CPU schedules in a lower priority task and wants to make sure
> > > overloaded CPUs know about it. It increments the rto_loop_next. Then it does
> > > an atomic_inc_return() on rto_loop_start. If the returned value is not "1",
> > > then it does atomic_dec() on rt_loop_start and returns. If the value is "1",
> > > then it will take the rto_lock to synchronize with a possible IPI being sent
> > > around to the overloaded CPUs.
> >
> > > + start = atomic_inc_return(&rq->rd->rto_loop_start);
> > > + if (start != 1)
> > > + goto out;
> >
> > > +out:
> > > + atomic_dec(&rq->rd->rto_loop_start);
> >
> >
> > Did you just write a very expensive test-and-set trylock?
>
> Probably. I didn't know we had a generic one. Where is it?
>
There isn't. What I was getting at though is that something like:
static inline bool rto_start_trylock(atomic_t *v)
{
int zero = 0;
return atomic_try_cmpxchg(v, &zero, 1);
}
static void rto_start_unlock(atomic_t *v)
{
atomic_set_release(v, 0);
}
Is more: clearer, faster and correct.
Clearer as that it better describes what it does, faster as that you
only have a single atomic, and more correct because it does a RELEASE in
the case we care about.
next prev parent reply other threads:[~2017-04-24 12:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-22 2:49 [RFC][PATCH tip/sched/core] sched/rt: Simplify the IPI rt balancing logic Steven Rostedt
2017-04-22 18:41 ` Steven Rostedt
2017-04-24 8:51 ` Peter Zijlstra
2017-04-24 12:43 ` Steven Rostedt
2017-04-24 12:46 ` Steven Rostedt
2017-04-24 12:52 ` Peter Zijlstra [this message]
2017-04-24 13:28 ` Steven Rostedt
2017-04-24 13:50 ` Peter Zijlstra
2017-04-24 8:57 ` Peter Zijlstra
2017-04-24 12:43 ` Steven Rostedt
2017-04-24 15:53 ` [PATCH RT v2] " Steven Rostedt
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=20170424125200.vxfmehm4tpdpeisc@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bristot@redhat.com \
--cc=jkacur@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=williams@redhat.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;
as well as URLs for NNTP newsgroup(s).