linux-kernel - Re: [RFC PATCH v8 1/9] Restartable sequences system call

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFw95UtYhpaiX5LgzmmjL==+vbFQcYtFvkxYcEBOtyXzMQ@mail.gmail.com>
Date:   Fri, 19 Aug 2016 13:59:28 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Josh Triplett <josh@...htriplett.org>
Cc:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Andy Lutomirski <luto@...capital.net>,
        Dave Watson <davejwatson@...com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Paul Turner <pjt@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Russell King <linux@....linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Andrew Hunter <ahh@...gle.com>,
        Andi Kleen <andi@...stfloor.org>, Chris Lameter <cl@...ux.com>,
        Ben Maurer <bmaurer@...com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 1:44 PM, Josh Triplett <josh@...htriplett.org> wrote:
>
> The combination of CPU number and restartable sequence allows userspace
> to write "per-CPU" rather than "per-thread" algorithms, just as the
> kernel can.  The kernel can do that with preempt_disable().  Userspace
> can do it with "tell me my CPU and restart me if preempted".

Yes, I understand what the patch series wants to do. But there hasn't
been a lot of discussion about why per-cpu would be better than
per-thread, or who would actually use this.

The kernel cares about per-cpu, because as far as the kernel is
concerned, that largely _is_ threading inside the kernel.

I'd feel a lot more warm and fuzzy about this all if I'd also see what
the usage scenario is, and then the numbers on top of that.

We really _have_ had too many clever interfaces that basically never
saw any real use, because the application writers don't want to limit
themselves to just Linux, and even if they are happy to do that, they
don't want to then limit themselves to a fairly modern kernel, and
they don't want to have two different code bases.

For example, there's been a talk about number of instructions and
cycles on ARMv7, but it's not clear whether the use case is going to
care about tens of cycles of overhead much less individual instruction
counts. Those instruction counts may matter when you benchmark an
individual "cpu-atomic add", but may not matter when you actually
benchmark something much bigger.

And if people end up waiting for kernel support to be universally
available, then ARMv7 isn't even all that relevant any more. It takes
years for things like this to percolate out. In the android space, you
get new hardware quicker than you get new software..

           Linus