Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1184582imm; Fri, 22 Jun 2018 11:47:54 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIDpA05n5qf+54PUSams+knNw/zE2n+/pjI/C015qakuojKdJ/7oIgiV141wMWG1xjB/LIF X-Received: by 2002:a63:449:: with SMTP id 70-v6mr2465152pge.229.1529693274448; Fri, 22 Jun 2018 11:47:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529693274; cv=none; d=google.com; s=arc-20160816; b=cMDQuDY6ScZp3AkvhsM0GoWEVcROVwZGloa6PDDOvEDRRsPPyVwYvHAF6MwI4J0R/1 MCNUGxt3a0RLJyxTp+z7GckO4cirkw/QP5pwX9UFI6R9iCyWrM7GLv7q5M+w1lnoHOsK l4w7RTszQHALZ1MnlTmrSSbRyXpTJrF13SUiJmM8UQ2xMdMrJdLOlgauTScVatw6JS4G DkawQpazPKh3IpQfjVKO8HH8GkfUDL5W1jNFUymzSEPUILBgWebKuI8xUqhFfpk8qZl7 bAz/2sBMpxDF+muqq4NMLo8LCOOzAbL/4aiC+7lREzuRAPlfRW5SqukfUpuqoETqVbx6 S9Wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:subject:cc:to:from :arc-authentication-results; bh=rsXMMCoWy048NPF9k7F65mxAorrte4H7+KFBL9lapBo=; b=LrDB9J5pzFQ+f2vJFY23Ggkjkd0eZqOBEeA+TjlEz3l+jIyJTIFmQoYcy7U4iYSdAw GW0Oks2c7dHwSHORk/F6bGhv/NSRWLndRVZz5uTKUZZpNy0vUwPPdomEmrpMczx3d0e6 VMnBo1MnH6Z1alOV67F2+fmCKJyHo1cBdKXnzXV1KWteclaQItToTp9xfTBPWWPT5iOm PgtWTFL5xYk35JdotS7ewCe6zMIOVEBobk1FfFEw02Stu15Qm4Uy3fSSJmX7nIg4Q6Ge Sylqhx0SAgOW94dmOl5zAb7mEQcfafkU7Yy1AcWs7cNqKkB+E6HrYseJtTbVxHEVhHsQ EAPg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f69-v6si8106815plb.503.2018.06.22.11.47.39; Fri, 22 Jun 2018 11:47:54 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934324AbeFVSqe convert rfc822-to-8bit (ORCPT + 99 others); Fri, 22 Jun 2018 14:46:34 -0400 Received: from mga03.intel.com ([134.134.136.65]:7323 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933878AbeFVSqc (ORCPT ); Fri, 22 Jun 2018 14:46:32 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2018 11:46:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,258,1526367600"; d="scan'208";a="61417239" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga003.jf.intel.com with ESMTP; 22 Jun 2018 11:46:31 -0700 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 22 Jun 2018 11:46:31 -0700 Received: from crsmsx102.amr.corp.intel.com (172.18.63.137) by FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 22 Jun 2018 11:46:31 -0700 Received: from crsmsx101.amr.corp.intel.com ([169.254.1.79]) by CRSMSX102.amr.corp.intel.com ([169.254.2.58]) with mapi id 14.03.0319.002; Fri, 22 Jun 2018 12:46:29 -0600 From: "Bae, Chang Seok" To: Thomas Gleixner CC: Andy Lutomirski , "H . Peter Anvin" , "Ingo Molnar" , Andi Kleen , Dave Hansen , "Metzger, Markus T" , "Shankar, Ravi V" , LKML Subject: RE: [PATCH v4 6/7] x86/vdso: Introduce CPU number helper functions Thread-Topic: [PATCH v4 6/7] x86/vdso: Introduce CPU number helper functions Thread-Index: AQHUCOybRPGJl8Bq10OSvRa4GMCSkqRsygwA///TMoI= Date: Fri, 22 Jun 2018 18:46:28 +0000 Message-ID: References: <1529536506-26237-1-git-send-email-chang.seok.bae@intel.com> <1529536506-26237-7-git-send-email-chang.seok.bae@intel.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.86.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, 22 Jun 2018, Thomas Gleixner wrote: > On Wed, 20 Jun 2018, Chang S. Bae wrote: > > CPU number initialization in vDSO is now a bit cleaned up by > > the new helper functions. The helper functions will take > > care of combing CPU and node number and reading each from > s/combing/combining/ please Will fix. > > @@ -18,9 +18,9 @@ __vdso_getcpu(unsigned *cpu, unsigned *node, struct getcpu_cache *unused) > > p = __getcpu(); > While we are touching this, can we please as a first step change __getcpu() > to something else? I've tripped over this several times in the past and > confused it with a (nonexisting) variant of get_cpu(). How about __vdso_get_cpudata()? > > #ifdef CONFIG_NUMA > > node = cpu_to_node(cpu); > > #endif > While at it please get rid of the ifdeffery. If CONFIG_NUMA=n then > cpu_to_node(cpu) resolves to (0). Okay, will fix this. > > > > if (cpu) > > - *cpu = p & VGETCPU_CPU_MASK; > > + *cpu = lsl_tscp_to_cpu(p); > > > > if (node) > > - *node = p >> 12; > > + *node = lsl_tscp_to_node(p); > > Are these new helpers going to be used at some other place than this? If > not, then there is really no point at all. Then just go and make this: > > __vdso_getcpu(unsigned *cpu, unsigned *node, struct getcpu_cache *unused) > { > vdso_read_cpu_and_node(cpu, node); > return 0; > } > > @@ -340,19 +340,19 @@ static void vgetcpu_cpu_init(void *arg) > > int cpu = smp_processor_id(); > > struct desc_struct d = { }; > > unsigned long node = 0; > > + unsigned long cpu_number = 0; > > That's hardly a CPU number. It's encoded CPU and node information. > > > + cpu_number = make_lsl_tscp(cpu, node); > > So the whole thing can be reduced to: > > u64 cpudata = vdso_encode_cpu_and_node(cpu, cpu_to_node(cpu)); > > Or some other sensible function name. Now, for these helper function renaming, I would like to check it from Andy. Thanks, Chang