[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160407153948.GH24771@twins.programming.kicks-ass.net>
Date: Thu, 7 Apr 2016 17:39:48 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...hat.com>,
Paul Turner <commonly@...il.com>,
Andi Kleen <andi@...stfloor.org>, Chris Lameter <cl@...ux.com>,
Dave Watson <davejwatson@...com>,
Josh Triplett <josh@...htriplett.org>,
Linux API <linux-api@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrew Hunter <ahh@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC PATCH 0/3] restartable sequences v2: fast user-space percpu
critical sections
On Thu, Apr 07, 2016 at 05:24:32PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 07:35:26AM -0700, Andy Lutomirski wrote:
> > That way we could take an async signal, handle it, and resume, even in
> > the middle of a commit, without aborting. Of course, if the signal
> > hander tried to access the same rseq-protected resource, it would bump
> > the event counter and cause an abort.
>
> Ah, so what happens if the signal happens before the commit but after
> the load of the seqcount?
>
> Then, even if the signal motifies the count, we'll not observe.
Ah, and the same is true for preemptions. Which is why all this was
preemption driven, and not migration driven.
Powered by blists - more mailing lists