Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp4270707imm; Mon, 25 Jun 2018 12:41:51 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIuGtLB6QKB1tpIlP9CraZppdt4jDlhzZ0bhzYy37xGB9mb/wy2zxNIAfIlpnk64XltFuCw X-Received: by 2002:a63:647:: with SMTP id 68-v6mr5489697pgg.205.1529955711719; Mon, 25 Jun 2018 12:41:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529955711; cv=none; d=google.com; s=arc-20160816; b=GoZXI6ClSqaDgxcZk8lO9noDq0rK2S/+BLXgmMxcto9q075lLMH7qE4JpB5/b+xLP2 N7VTTQ2LlhFsSJA+p6NgXaFagzn7a41I3Ca4PuwSKGgW+EAKLRKKv5BXEg7/OLpKCryh UwAM+EaHhfA6ijQycP331A9OFUwPTPaH7UUoHq/8/wmFHVcGOGjZRx9huMo7AR1oE/Vw 7XglMGSRVM629cl4e+8OnNunJFsyk0AXQ2rT2vjK6ro8Hzu86IIDN1tRA4a2FyuR//Dk c++o2vQhI0KR4yU/fJwszuQOGv6S+9x5WQQhCC6x9EfU+CKPgtb8mV+Zu5QejAt2j6uL Veig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=g8zb9gIvcYljG4gPJgEAZ6huEPNZsTegIU+3/+c9vd0=; b=lzzIKhdUggcTdp1Da6mDPS17S7ZueRuAwHAXdqQTeLHtcEi5ysC22fSk6dNHpZ9EaF P2woS/LZuQH6kMTvZIInaf2zrLwo/A9rE1250lislzhSITIOvZm6LSO34BkPee1scUAE AaoY7C9svB814pq27OM9wTmQhmDNbHtM3rV+6dT/1aqLzGmnDe5jk5aDo5zxFDdGgBCa DF1s8y1NlkSw3U8rtmtF9EdgLFjRVB69M2TdhYlNAhprrD433FY7UvsDcXrb7DqlPleb a9Rzn7liAnL28AwSUh0T7eotCI6BmHZAutRBR7CkU72GMQjVrmL2Gn6kWkG5z+I8DoMB UBnA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d65-v6si15410677pfg.142.2018.06.25.12.41.37; Mon, 25 Jun 2018 12:41:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964889AbeFYTky (ORCPT + 99 others); Mon, 25 Jun 2018 15:40:54 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:47467 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934940AbeFYTkx (ORCPT ); Mon, 25 Jun 2018 15:40:53 -0400 Received: from p4fea482e.dip0.t-ipconnect.de ([79.234.72.46] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fXXLs-0005L0-FZ; Mon, 25 Jun 2018 21:40:40 +0200 Date: Mon, 25 Jun 2018 21:40:40 +0200 (CEST) From: Thomas Gleixner To: "H. Peter Anvin" cc: Andy Lutomirski , "Bae, Chang Seok" , Ingo Molnar , Andi Kleen , Dave Hansen , "Metzger, Markus T" , "Ravi V. Shankar" , LKML , Peter Zijlstra Subject: Re: [PATCH v4 7/7] x86/vdso: Move out the CPU number store In-Reply-To: Message-ID: References: <1529536506-26237-1-git-send-email-chang.seok.bae@intel.com> <1529536506-26237-8-git-send-email-chang.seok.bae@intel.com> <80C1F514-1B4D-4CDC-BD46-6C3AA9601446@amacapital.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 25 Jun 2018, H. Peter Anvin wrote: > On 06/25/18 08:40, Thomas Gleixner wrote: > > On Fri, 22 Jun 2018, Andy Lutomirski wrote: > > > >> On Fri, Jun 22, 2018 at 11:02 AM Bae, Chang Seok > >> wrote: > >>> > >>>> Still setup_cpu_number() sucks. > >>> > >>> How about setup_cpu_and_node_number()? > >> > >> setup_fast_cpu_node_nr()? setup_cpunr_regs()? I don't have any > >> brilliant ideas. Thomas? > > > > It's really hard to find a good one. setup_cpu_node_cache() might work, but > > it's not brilliant either. > > > > Since this applies to the getcpu(2) system call (in addition to the > kernel usage), perhaps setup_getcpu()? Works for me.