linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Clark Williams <williams@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: [PATCH] sched: Do not release current rq lock on non contended double_lock_balance()
Date: Tue, 14 Jun 2016 14:02:28 -0400	[thread overview]
Message-ID: <20160614140228.0ecf15af@grimm.local.home> (raw)
In-Reply-To: <20160614115820.GD30921@twins.programming.kicks-ass.net>

On Tue, 14 Jun 2016 13:58:20 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> 
> The above puts a strict limit on hold time and is fair because of the
> queueing.
> 
> > +++ b/kernel/sched/sched.h
> > @@ -1548,10 +1548,15 @@ static inline int _double_lock_balance(struct rq *this_rq, struct rq *busiest)
> >  	__acquires(busiest->lock)
> >  	__acquires(this_rq->lock)
> >  {
> > +	int ret = 0;
> > +
> > +	if (unlikely(!raw_spin_trylock(&busiest->lock))) {
> > +		raw_spin_unlock(&this_rq->lock);
> > +		double_rq_lock(this_rq, busiest);
> > +		ret = 1;
> > +	}
> >  
> > +	return ret;
> >  }  
> 
> This relies on trylock no being allowed to steal the lock, which I think
> is true for all fair spinlocks (for ticket this must be true, but it is
> possible with qspinlock for example).
> 
> And it does indeed make the hold time harder to analyze.
> 
> For instance; pull_rt_task() does:
> 
> 	for_each_cpu() {
> 		double_lock_balance(this, that);
> 		...
> 		double_unlock_balance(this, that);
> 	}
> 
> Which, with the trylock, ends up with a max possible hold time of
> O(nr_cpus).

Sure, but I think we should try to limit that loop too, because that
loop itself is what is triggering the large latency for me, because
it constantly releases a spinlock and has to wait. This loop is done
with preemption disabled.

> 
> Unlikely, sure, but RT is a game of upper bounds etc.

Sure, but should we force worst case all the time?

We do a lot of optimization to allow for good throughput as well.

> 
> So should we maybe do something like:
> 
> 	if (unlikely(raw_spin_is_contended(&this_rq->lock) ||
> 	             !raw_spin_trylock(&busiest->lock))) {

Why do we care if this_rq is contended? That's exactly what causes
large latency to happen. Because when we let go of this_rq, this fast
path becomes much slower because now it must wait for whatever is
waiting on it to finish. The more CPUs you have, the bigger this issue
becomes.

If there's a loop on O(nr_cpus) (which is still technically O(1)) then
another CPU may need to wait for that loop to finish. But the loop
itself is kept tighter. If we always always release the lock, we allow
other CPUs to continue at the expense of the one CPU from continuing,
the K of that O(nr_cpus) becomes much larger and we consolidate the
latency all to a single CPU which may be the one that is running the
highest priority task in the system.

I'm seeing 100s us latency because of this. With this patch, that
latency disappears.

-- Steve



> 		raw_spin_unlock(&this_rq->lock);
> 		double_rq_lock(this_rq, busiest);
> 		ret = 1;
> 	}

  parent reply	other threads:[~2016-06-14 18:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-13 16:37 Steven Rostedt
2016-06-14 11:58 ` Peter Zijlstra
2016-06-14 17:52   ` Steven Rostedt
2016-06-14 18:02   ` Steven Rostedt [this message]
2016-06-14 19:42     ` Peter Zijlstra
2016-06-15 11:14     ` Peter Zijlstra
2016-06-15 16:13       ` 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=20160614140228.0ecf15af@grimm.local.home \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.com \
    --subject='Re: [PATCH] sched: Do not release current rq lock on non contended double_lock_balance()' \
    /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

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).