mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Balbir Singh <bsingharora@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Nicholas Piggin <nicholas.piggin@gmail.com>,
	Alexey Kardashevskiy <aik@ozlabs.ru>
Subject: Re: [RFC][PATCH] Fix a race between rwsem and the scheduler
Date: Wed, 31 Aug 2016 09:28:35 +0200	[thread overview]
Message-ID: <20160831072835.GB10138@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1e2e1a49-db2f-bdae-53b2-0bda225be472@gmail.com>

On Wed, Aug 31, 2016 at 01:41:33PM +1000, Balbir Singh wrote:
> On 30/08/16 22:19, Peter Zijlstra wrote:
> > On Tue, Aug 30, 2016 at 06:49:37PM +1000, Balbir Singh wrote:
> >>
> >>
> >> The origin of the issue I've seen seems to be related to
> >> rwsem spin lock stealing. Basically I see the system deadlock'd in the
> >> following state
> > 
> > As Nick says (good to see you're back Nick!), this is unrelated to
> > rwsems.
> > 
> > This is true for pretty much every blocking wait loop out there, they
> > all do:
> > 
> > 	for (;;) {
> > 		current->state = UNINTERRUPTIBLE;
> > 		smp_mb();
> > 		if (cond)
> > 			break;
> > 		schedule();
> > 	}
> > 	current->state = RUNNING;
> > 
> > Which, if the wakeup is spurious, is just the pattern you need.
> 
> Yes True! My bad Alexey had seen the same basic pattern, I should have been clearer
> in my commit log. Should I resend the patch?

Yes please.

> > There isn't an MB there. The best I can do is UNLOCK+LOCK, which, thanks
> > to PPC, is _not_ MB. It is however sufficient for this case.
> > 
> 
> The MB comes from the __switch_to() in schedule(). Ben mentioned it in a 
> different thread.

Right, although even without that, there is sufficient ordering, as the
rq unlock from the wakeup, coupled with the rq lock from the schedule
already form a load-store barrier.

> > Now, this has been present for a fair while, I suspect ever since we
> > reworked the wakeup path to not use rq->lock twice. Curious you only now
> > hit it.
> > 
> 
> Yes, I just hit it a a week or two back and I needed to collect data to
> explain why p->on_rq got to 0. Hitting it requires extreme stress -- for me
> I needed a system with large threads and less memory running stress-ng.
> Reproducing the problem takes an unpredictable amount of time.

What hardware do you see this on, is it shiny new Power8 chips which
have never before seen deep queues or something. Or is it 'regular' old
Power7 like stuff?

  reply	other threads:[~2016-08-31  7:28 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-30  8:49 Balbir Singh
2016-08-30  9:13 ` Nicholas Piggin
2016-08-30 12:19 ` Peter Zijlstra
2016-08-30 13:04   ` Oleg Nesterov
2016-08-30 14:13     ` Peter Zijlstra
2016-08-30 16:57       ` Oleg Nesterov
2016-08-30 18:34         ` Peter Zijlstra
2016-08-30 21:28           ` Benjamin Herrenschmidt
2016-08-31  7:18             ` Peter Zijlstra
2016-08-31 10:56               ` Benjamin Herrenschmidt
2016-08-31 13:31             ` Peter Zijlstra
2016-08-31 21:47               ` Benjamin Herrenschmidt
2016-09-01  6:49                 ` Balbir Singh
2016-09-01  6:57                 ` Peter Zijlstra
2016-09-01 14:17                   ` Boqun Feng
2016-09-01 15:33                     ` Peter Zijlstra
2016-08-30 21:25     ` Benjamin Herrenschmidt
2016-08-31  7:20       ` Peter Zijlstra
2016-08-31 10:55         ` Benjamin Herrenschmidt
2016-08-31  3:41   ` Balbir Singh
2016-08-31  7:28     ` Peter Zijlstra [this message]
2016-08-31 10:17       ` Balbir Singh
2016-08-31 10:57       ` Benjamin Herrenschmidt
2016-09-01  1:48       ` Alexey Kardashevskiy
2016-09-01 12:16         ` Alexey Kardashevskiy
2016-08-30 12:58 ` Oleg Nesterov
2016-08-31  3:25   ` Balbir Singh

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=20160831072835.GB10138@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=aik@ozlabs.ru \
    --cc=benh@kernel.crashing.org \
    --cc=bsingharora@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicholas.piggin@gmail.com \
    --cc=oleg@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

all inboxes | Powered by JetHome®