From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: [RFC PATCH for 4.18 00/16] Restartable Sequences Date: Sat, 28 Jul 2018 09:49:04 -0400 (EDT) Message-ID: <1210024721.6363.1532785744879.JavaMail.zimbra@efficios.com> References: <20180602124408.8430-1-mathieu.desnoyers@efficios.com> <20180727220115.GA18879@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180727220115.GA18879@amd> Sender: linux-kernel-owner@vger.kernel.org To: Pavel Machek , Carlos O'Donell , Florian Weimer 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 Jul 27, 2018, at 6:01 PM, Pavel Machek pavel@ucw.cz wrote: > Hi! > >> So for instance, this turns: >> >> int cpu = rseq_per_cpu_lock(lock, target_cpu); >> [...] >> rseq_per_cpu_unlock(lock, cpu); >> >> into >> >> int cpu = rseq_this_cpu_lock(lock); >> [...] >> rseq_per_cpu_unlock(lock, cpu); >> >> and: >> >> per_cpu_list_push(list, node, target_cpu); >> [...] >> per_cpu_list_pop(list, node, target_cpu); >> >> into >> >> this_cpu_list_push(list, node, &cpu); /* cpu is an output parameter. */ >> [...] >> node = this_cpu_list_pop(list, &cpu); /* cpu is an output parameter. */ >> >> Eventually integrating cpu_opv or some alternative will allow passing >> the cpu number as parameter rather than requiring the algorithm to work >> on the current CPU. >> >> The second effect of not having the cpu_opv fallback is that >> line and instruction single-stepping with a debugger transforms rseq >> critical sections based on retry loops into never-ending loops. >> Debuggers need to use the __rseq_table section to skip those critical >> sections in order to correctly behave when single-stepping a thread >> which uses rseq in a retry loop. However, applications which use an >> alternative fallback method rather than retrying on rseq fast-path abort >> won't be affected by this kind of single-stepping issue. >> >> Thanks for your feedback! > > Would it make sense to include Documentation/ patch? I guess at least > manpage describing the syscall will be needed.... Hi Pavel, Documentation-wise, I have posted a rseq man page rfc here: https://lkml.kernel.org/r/20180616195803.29877-1-mathieu.desnoyers@efficios.com comments are welcome! It does not include any details about user-space library APIs though, as this is not the purpose of the syscall documentation. We're currently discussing integration of rseq thread registration into glibc. Once this is settled, I plan to provide a librseq which will contain headers and documentation on how to use rseq without having to re-create the low-level assembly every time. Does this plan make sense to you ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com