From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751470AbdJ2JI2 (ORCPT ); Sun, 29 Oct 2017 05:08:28 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:38052 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750915AbdJ2JI1 (ORCPT ); Sun, 29 Oct 2017 05:08:27 -0400 Date: Sun, 29 Oct 2017 10:08:17 +0100 (CET) From: Thomas Gleixner To: Andy Lutomirski cc: Linus Torvalds , Peter Zijlstra , X86 ML , Borislav Petkov , "linux-kernel@vger.kernel.org" , linux-abi@vger.kernel.org Subject: Re: Can we break RDPID/RDTSCP ABI ASAP and see if it's okay? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 28 Oct 2017, Andy Lutomirski wrote: > We currently do this on boot: > > write_rdtscp_aux((node << 12) | cpu); > > This *sucks*. It means that, to very quickly obtain the CPU number > using RDPID, an ALU op is needed. It also doesn't bloody work on > systems with more than 4096 CPUs. > > IMO it should be ((u64)node << 32) | cpu. Then getting the CPU number is just: That breaks 32bit > RDPID %rax > MOVL %eax, %eax > > I'm thinking about this because rseq users could avoid ever *loading* > the rseq cacheline if they used RDPID to get the CPU number, and it > would be nice to give them a sane way to do it. > > This won't break any existing RDPID users if we do it quickly because > there aren't any (the CPUs aren't available). I would be a bit > surprised if anyone uses RDTSCP for this because it's absurdly slow. What we can do on 64bit is: ((u64) cpu << 32) | (node << 12) | (cpu & 0xfff) That does not solve the ALU op problem but works on both 32 and 64 bit and on systems with more than 4096 CPUs. Thanks, tglx