Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752948AbcJJP3v (ORCPT ); Mon, 10 Oct 2016 11:29:51 -0400 Received: from foss.arm.com ([217.140.101.70]:49074 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752476AbcJJP3u (ORCPT ); Mon, 10 Oct 2016 11:29:50 -0400 Date: Mon, 10 Oct 2016 16:29:48 +0100 From: Will Deacon To: Fredrik =?iso-8859-1?Q?Markstr=F6m?= Cc: Russell King - ARM Linux , Robin Murphy , Mark Rutland , Kees Cook , Arnd Bergmann , Ard Biesheuvel , Linus Walleij , Nicolas Pitre , kristina.martsenko@arm.com, linux-kernel@vger.kernel.org, Masahiro Yamada , Chris Brandt , Michal Marek , Zhaoxiu Zeng , linux-arm-kernel@lists.infradead.org, Jonathan Austin , mathieu.desnoyers@efficios.com Subject: Re: [PATCH v2] arm: Added support for getcpu() vDSO using TPIDRURW Message-ID: <20161010152948.GD14561@arm.com> References: <1475589000-29315-1-git-send-email-fredrik.markstrom@gmail.com> <1475595363-4272-1-git-send-email-fredrik.markstrom@gmail.com> <20161004170741.GC29008@leverpostej> <50e025e0-7052-9b15-3b3e-36d1d9dfd695@arm.com> <20161005195359.GR1041@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2592 Lines: 56 Hi Fredrik, [adding Mathieu -- background is getcpu() in userspace for arm] On Thu, Oct 06, 2016 at 12:17:07AM +0200, Fredrik Markstr?m wrote: > On Wed, Oct 5, 2016 at 9:53 PM, Russell King - ARM Linux > wrote: > > On Wed, Oct 05, 2016 at 06:48:05PM +0100, Robin Murphy wrote: > >> On 05/10/16 17:39, Fredrik Markstr?m wrote: > >> > The approach I suggested below with the vDSO data page will obviously > >> > not work on smp, so suggestions are welcome. > >> > >> Well, given that it's user-writeable, is there any reason an application > >> which cares couldn't simply run some per-cpu threads to call getcpu() > >> once and cache the result in TPIDRURW themselves? That would appear to > >> both raise no compatibility issues and work with existing kernels. > > > > There is - the contents of TPIDRURW is thread specific, and it moves > > with the thread between CPU cores. So, if a thread was running on CPU0 > > when it cached the getcpu() value in TPIDRURW, and then migrated to CPU1, > > TPIDRURW would still contain 0. > > > > I'm also not in favour of changing the TPIDRURW usage to be a storage > > repository for the CPU number - it's far too specific a usage and seems > > like a waste of hardware resources to solve one problem. > > Ok, but right now it's nothing but a (architecture specific) piece of TLS, > which we have generic mechanisms for. From my point of view that is a waste of > hardware resources. > > > As Mark says, it's an ABI breaking change too, even if it is under a config > option. > > I can't argue with that. If it's an ABI it's an ABI, even if I can't imagine > why anyone would use it over normal tls... but then again, people probably do. > > So in conclusion I agree and give up. Rather than give up, you could take a look at the patches from Mathieu Desnoyers, that tackle this in a very different way. It's also the reason we've been holding off implementing an optimised getcpu in the arm64 vdso, because it might all well be replaced by the new restartable sequences approach: http://lkml.kernel.org/r/1471637274-13583-1-git-send-email-mathieu.desnoyers@efficios.com He's also got support for arch/arm/ in that series, so you could take them for a spin. The main thing missing at the moment is justification for the feature using real-world code, as requested by Linus: http://lkml.kernel.org/r/CA+55aFz+Q33m1+ju3ANaznBwYCcWo9D9WDr2=p0YLEF4gJF12g@mail.gmail.com so if your per-cpu buffer use-case is compelling in its own right (as opposed to a micro-benchmark), then you could chime in over there. Will