All of lore.kernel.org
 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: Wed, 15 Jun 2016 12:13:53 -0400	[thread overview]
Message-ID: <20160615121353.7194c68b@grimm.local.home> (raw)
In-Reply-To: <20160615111453.GG30909@twins.programming.kicks-ass.net>

On Wed, 15 Jun 2016 13:14:53 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> OK, so should not the whole HAVE_RT_PUSH_IPI thing have avoided that
> loop entirely? And therefore made the point moot?

I believe there was another issue that we had in our tests. But I don't
have the trace available with me. I'll rerun the tests when I get back
home and have some more concrete examples for you.

> 
> In any case, can't we add another cpupri for pushable tasks and use that
> to find the highest priority task to pull and avoid the loop thus?

I thought about this too, but I was a bit concerned about complexities
this would add. But I can look into it. Currently I'm in NYC for
personal reasons and will take a look at this when I get back.

-- Steve

      reply	other threads:[~2016-06-15 16:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-13 16:37 [PATCH] sched: Do not release current rq lock on non contended double_lock_balance() Steven Rostedt
2016-06-14 11:58 ` Peter Zijlstra
2016-06-14 17:52   ` Steven Rostedt
2016-06-14 18:02   ` Steven Rostedt
2016-06-14 19:42     ` Peter Zijlstra
2016-06-15 11:14     ` Peter Zijlstra
2016-06-15 16:13       ` Steven Rostedt [this message]

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=20160615121353.7194c68b@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 \
    /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.