From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: [RFC PATCH for 4.16 02/21] rseq: Introduce restartable sequences system call (v12) Date: Thu, 14 Dec 2017 19:57:08 +0000 (UTC) Message-ID: <1772818221.34575.1513281428902.JavaMail.zimbra@efficios.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20171214194853.GE3326@worktop> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Peter Zijlstra 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 List-Id: linux-api@vger.kernel.org ----- On Dec 14, 2017, at 2:48 PM, Peter Zijlstra peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.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. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com