From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: [RFC PATCH for 4.18 00/14] Restartable Sequences Date: Thu, 3 May 2018 14:04:24 -0400 (EDT) Message-ID: <702933118.10410.1525370664578.JavaMail.zimbra@efficios.com> References: <20180430224433.17407-1-mathieu.desnoyers@efficios.com> <660904075.9201.1525276988842.JavaMail.zimbra@efficios.com> <1718748931.10084.1525363941807.JavaMail.zimbra@efficios.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Daniel Colascione Cc: Peter Zijlstra , "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 , Chris Lameter , Ben Maurer , rostedt , Josh Triplett , Linus Torvalds , Catalin Marinas List-Id: linux-api@vger.kernel.org ----- On May 3, 2018, at 12:22 PM, Daniel Colascione dancol@google.com wrote: > On Thu, May 3, 2018 at 9:12 AM Mathieu Desnoyers < > mathieu.desnoyers@efficios.com> wrote: >> By the way, if we eventually find a way to enhance user-space mutexes in > the >> fashion you describe here, it would belong to another TLS area, and would >> be registered by another system call than rseq. I proposed a more generic >> "TLS area registration" system call a few years ago, but Linus told me he >> wanted a system call that was specific to rseq. If we need to implement >> other use-cases in a TLS area shared between kernel and user-space in a >> similar fashion, the plan is to do it in a distinct system call. > > If we proliferate TLS areas; we'd have to register each one upon thread > creation, adding to the overall thread creation path. There's already a > provision for versioning the TLS area. What's the benefit of splitting the > registration over multiple system calls? See the original discussion thread at https://lkml.org/lkml/2016/4/7/502 Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com