Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752650AbdLNUJ5 (ORCPT ); Thu, 14 Dec 2017 15:09:57 -0500 Received: from merlin.infradead.org ([205.233.59.134]:35762 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752046AbdLNUJx (ORCPT ); Thu, 14 Dec 2017 15:09:53 -0500 Date: Thu, 14 Dec 2017 21:09:26 +0100 From: Peter Zijlstra To: Mathieu Desnoyers Cc: Chris Lameter , "Paul E. McKenney" , Boqun Feng , Andy Lutomirski , Dave Watson , linux-kernel , linux-api , Paul Turner , Andrew Morton , Russell King , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andrew Hunter , Andi Kleen , Ben Maurer , rostedt , Josh Triplett , Linus Torvalds , Catalin Marinas , Will Deacon , Michael Kerrisk , Alexander Viro Subject: Re: [RFC PATCH for 4.16 02/21] rseq: Introduce restartable sequences system call (v12) Message-ID: <20171214200926.GF3326@worktop> References: <20171214161403.30643-1-mathieu.desnoyers@efficios.com> <20171214161403.30643-3-mathieu.desnoyers@efficios.com> <12046460.34426.1513275177081.JavaMail.zimbra@efficios.com> <20171214194853.GE3326@worktop> <1772818221.34575.1513281428902.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1772818221.34575.1513281428902.JavaMail.zimbra@efficios.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1529 Lines: 32 On Thu, Dec 14, 2017 at 07:57:08PM +0000, Mathieu Desnoyers wrote: > ----- On Dec 14, 2017, at 2:48 PM, Peter Zijlstra peterz@infradead.org wrote: > > > On Thu, Dec 14, 2017 at 12:50:13PM -0600, Christopher Lameter wrote: > >> Ultimately I wish fast increments like done by this_cpu_inc() could be > >> implemented in an efficient way on non x86 platforms that do not have > >> cheap instructions like that. > > > > So the problem isn't migration; for that we could wrap the operation in > > preempt_disable() which is not more expensive than rseq would be. And a > > lot more deterministic. > > > > The problem instead is interrupts, which can result in nested load-store > > operations, and that comes apart. This then means having to disable > > interrupts over these things and _that_ is expensive. > > Then could we consider checking a per task-struct rseq_cs pointer when > returning from interrupt handler ? This rseq_cs pointer would track > kernel restartable sequences. This would also work for NMI handlers. I really don't much like making the interrupt handlers more expensive for this. And I don't think NMIs are a real worry, you should be very careful when you share state with any of them in any case. Also; what you can do is soft interrupt disable, which is effectively the oppose approach, instead of restarting the sequence, you delay the interrupt handler. And that has the obvious benefit of making all the local_irq_disable/enable crud much faster all over. This is something PowerPC already does.