Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753531AbdLNVOJ (ORCPT <rfc822;w@1wt.eu>);
        Thu, 14 Dec 2017 16:14:09 -0500
Received: from resqmta-ch2-08v.sys.comcast.net ([69.252.207.40]:56824 "EHLO
        resqmta-ch2-08v.sys.comcast.net" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1753488AbdLNVOE (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 14 Dec 2017 16:14:04 -0500
Date: Thu, 14 Dec 2017 15:14:00 -0600 (CST)
From: Christopher Lameter <cl@linux.com>
X-X-Sender: cl@nuc-kabylake
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
cc: Peter Zijlstra <peterz@infradead.org>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Andy Lutomirski <luto@amacapital.net>,
        Dave Watson <davejwatson@fb.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        linux-api <linux-api@vger.kernel.org>, Paul Turner <pjt@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Russell King <linux@arm.linux.org.uk>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Andrew Hunter <ahh@google.com>,
        Andi Kleen <andi@firstfloor.org>, Ben Maurer <bmaurer@fb.com>,
        rostedt <rostedt@goodmis.org>, Josh Triplett <josh@joshtriplett.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will.deacon@arm.com>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [RFC PATCH for 4.16 02/21] rseq: Introduce restartable sequences
 system call (v12)
In-Reply-To: <1537392285.34532.1513279478488.JavaMail.zimbra@efficios.com>
Message-ID: <alpine.DEB.2.20.1712141512360.8945@nuc-kabylake>
References: <20171214161403.30643-1-mathieu.desnoyers@efficios.com> <20171214161403.30643-3-mathieu.desnoyers@efficios.com> <alpine.DEB.2.20.1712141033100.6249@nuc-kabylake> <12046460.34426.1513275177081.JavaMail.zimbra@efficios.com>
 <alpine.DEB.2.20.1712141238180.8340@nuc-kabylake> <1537392285.34532.1513279478488.JavaMail.zimbra@efficios.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-CMAE-Envelope: MS4wfA7BeCBDUt5FTg7QoQO6f1UqUOpy1cVu10rVx4w8laKNnJS/1djc4B+RyHSnXZwITMKb9CkUtaFiYKa6+1R+zhpH+X4MBwHq2uGIB0wHy/9m3emZYK/r
 9iR7TPC7rDZltLLkv+HBYFJ/U88sikl48KSr5I3qV6phs+ZfIEYxAa8zt119KATjNR1aJIS+C+pLWCQXSViSmC/5RQHBvU+H7ZrY0EqU95lDsDiuSkAeP9HJ
 D1HIZ7LOqBJoaO2DKwfZSOZVeCKrPM/S5zKf2eeApNABdq9pO2zUII/1Wdw7wKaZfM+INDHPGWyVB6CK7nOJCSqitvXlEfQduOq2IzjkrhusLv4Hn2hbLxb3
 MX1Eha5Bf3ZivyRotBiCTOZkiZXaohQaMr0Syz5yyHghIN5vG2yQDqTzyDggVe+QrPAO4/EQmnMsppGPnjlurf1FJ3lnCeUhAk0fE909j6kfx7UigxoIuVFw
 7yJHdS+H7pg5u3batzq88WimqftxizbJ19TuV7WmBxCYLcAZRBwlGT6odsccFDywvrAH4ruXbLRP/96ba6xcxHspeciAH1jqdT28am07nxX90uEPV8eIKk3G
 4ZDo2Gt3FJkmwr18fwfssZw9np+3IvMbI+kMFfZ2KaIWcJ5Ue7urmLbaWzXb/wr+GNX7Us/UmgbK1sq0xh0EN+nWzwt+ImailKEvEoQgXxuEKPQOGhF8SYKn
 4d3rSMqRCysfVaZUEktvIBq0Tq2tb//lTnkf0u0eKj5isSlxr9+Nw6Ew8EFijfYhZBRXX35PE/QzPsz4/xW6ngSXmJ+tYuyzZN6PW6HUgYGkKDvPgfVlt93L
 tSYzq3QiYvssrKiBe/sSKZuEZW0cTvStx4T3qViRf+tZiwhX8Nd/v5MTPnjWHc5g1vOZkpthWjiyh5dimIo=
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 519
Lines: 12

On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:

> If we port this concept to kernel-space (as I start to understand
> would be your wish), then a simple pointer store to the current
> task_struct would suffice.

Certainly such a port would be beneficial for non x86 archs.

But my company has extensive user space code that maintains a lot of
counters and does other tricks to get full performance out of the
hardware. Such a mechanism would also be good from user space. Why keep
the good stuff only inside the kernel?