Received: by 10.192.165.156 with SMTP id m28csp967218imm; Wed, 18 Apr 2018 01:23:47 -0700 (PDT) X-Google-Smtp-Source: AIpwx48WLjbwyxiiFFWHJOEYbwQr+VqGbI132/L4s9Hprg6ffrCfKyHXUO936iKOrGQuzzDKZPcg X-Received: by 10.101.82.194 with SMTP id z2mr996544pgp.69.1524039827068; Wed, 18 Apr 2018 01:23:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524039827; cv=none; d=google.com; s=arc-20160816; b=jsilrr9udx31lzO0HlsHgaJ0pYtDfY6b4MYirb+erpLPsTjSUJkEkXOI8GWuAUTfBf w5iZ5dGEvFWWr0V3TJYLf9SCVLl3BiGCBPUI0QCzC9kS4bqzB9aLVG9m+56Ukc3F+LDL U2eT65cCw2LQKYCRmjb9VPcFz3ISVMZozvznsmE76vCxyLjGYcsRtjTIDoyajcSZQsBl JD+hP/2Dix0Xy17xKPYzZOHv218+k6nD061CcDVnfY5BfuSJtDzNzahlFOogrEECogd+ pdGXKDYXS+pW7AQfy0ASYt1t0j7t7cjkLPth/4zqw8FSuQT9LtxdutexJeXq75Fj17AE i2zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language:thread-index :content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=Q8OfKqT1YQQRKj8lSdx+LBewCL9A2iV/Lb0waYFgg/0=; b=z69C6JBDgR1WLV2wSHSlV3EAbGf3DD9shcTlyMsdzrj/ZetSkXyeunaIz6wahVyrQY T6ObOdOoTRvUiWgx1GwEsFZc+uP/XWACcWgTkjyAzaXOY54NvoGKsi3rCoatINoAO2Y3 PoJh0S7xTI29+EWrxCoYLtVjp4mgQg3wdj3gkiJ+WoOVcOH1LA41lWU/D17OPCYGPf6u YYanCfmDmzkxNX7plmjg5ygIVbkWeBcDBZh92VIXyCknhG2eekVjiSEsX1vxNfmi0kLA BM1x66SEzICkVsIPcUunlaOVlb04pCuNdD1w9S0jFxDmf1B3bCnPjGuGB4D+csnUx7sx PeTw== 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 x1si663490pgp.89.2018.04.18.01.23.33; Wed, 18 Apr 2018 01:23:47 -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 S1753346AbeDRIW0 (ORCPT + 99 others); Wed, 18 Apr 2018 04:22:26 -0400 Received: from zxshcas1.zhaoxin.com ([180.169.121.91]:31419 "EHLO ZXSHCAS1.zhaoxin.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752927AbeDRIWY (ORCPT ); Wed, 18 Apr 2018 04:22:24 -0400 Received: from zxbjmbx3.zhaoxin.com (10.29.252.165) by ZXSHCAS1.zhaoxin.com (10.28.252.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1261.35; Wed, 18 Apr 2018 16:22:18 +0800 Received: from TIMGUOE40 (10.29.8.18) by zxbjmbx3.zhaoxin.com (10.29.252.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1261.35; Wed, 18 Apr 2018 16:22:16 +0800 From: David Wang To: 'Thomas Gleixner' CC: , , , , , , , , , , Subject: Re: [PATCH] x86/centaur: report correct CPU/cache topology Date: Wed, 18 Apr 2018 16:21:48 +0800 Message-ID: <000001d3d6ee$4bfc9000$e3f5b000$@zhaoxin.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdPW7erdIYHYcKndRkWw0z4fCzKc0g== Content-Language: zh-cn X-Originating-IP: [10.29.8.18] X-ClientProxiedBy: zxbjmbx1.zhaoxin.com (10.29.252.163) To zxbjmbx3.zhaoxin.com (10.29.252.165) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Mail----- > Sender: Thomas Gleixner [mailto:tglx@linutronix.de] > Time : 2018/4/17 18:16 > Receiver: David Wang > CC: mingo@redhat.com; hpa@zytor.com; mingo@kernel.org; > x86@kernel.org; linux-kernel@vger.kernel.org; brucechang@via- > alliance.com; cooperyan@zhaoxin.com; qiyuanwang@zhaoxin.com; > benjaminpan@viatech.com; lukelin@viacpu.com; timguo@zhaoxin.com > Subject: Re: [PATCH] x86/centaur: report correct CPU/cache topology > > On Wed, 4 Apr 2018, David Wang wrote: > > > This patch is used to support multi-core Centaur CPU. After using this > > patch, we can get correct CPU topology and correct cache topology. > > David. This changelog is pretty useless. First of all, please do not use 'This > patch ..'. We all know already that this is a patch. > Documentation/process/submitting-patches.rst has a good explanation > about writing changelogs. > > The changelog should explain why it does something. Let me give you an > example: > > Centaur CPUs enumerate the cache topology in the same way as Intel CPUs, > but the functionality is unused so far. The Centaur init code also misses > to initialize x86_cpuinfo::max_cores so the CPU topology cannot be > desribed correctly, > > Initialize x86_cpuinfo::max_cores and invoke init_intel_cacheinfo() to > make CPU and cache topology information available and correct. > > See? I'm neither using 'this patch' nor 'We/I' as I'm not impersonatimg the > code. It's all factual instead. > > Signed-off-by: David Wang > > --- > > arch/x86/kernel/cpu/centaur.c | 20 ++++++++++++++++++++ > > 1 file changed, 20 insertions(+) > > > > diff --git a/arch/x86/kernel/cpu/centaur.c > > b/arch/x86/kernel/cpu/centaur.c index e5ec0f1..713e4db 100644 > > --- a/arch/x86/kernel/cpu/centaur.c > > +++ b/arch/x86/kernel/cpu/centaur.c > > @@ -112,6 +112,19 @@ static void early_init_centaur(struct cpuinfo_x86 > *c) > > } > > } > > > > +static int centaur_num_cpu_cores(struct cpuinfo_x86 *c) { > > + unsigned int eax, ebx, ecx, edx; > > + > > + if (c->cpuid_level < 4) > > + return 1; > > + cpuid_count(4, 0, &eax, &ebx, &ecx, &edx); > > + if (eax & 0x1f) > > + return (eax >> 26) + 1; > > + else > > + return 1; > > This is a bad copy of intel_num_cpu_cores(). See for the subtle difference. > Please rename the intel function and move it to common.c > > > static void init_centaur(struct cpuinfo_x86 *c) { #ifdef > > CONFIG_X86_32 @@ -128,6 +141,13 @@ static void init_centaur(struct > > cpuinfo_x86 *c) > > clear_cpu_cap(c, 0*32+31); > > #endif > > early_init_centaur(c); > > + > > + init_intel_cacheinfo(c); > > + c->x86_max_cores = centaur_num_cpu_cores(c); #ifdef > CONFIG_X86_32 > > + detect_ht(c); > > +#endif > > Can you please create a stub inline of detect_ht() for the !32bit case and get > rid of these #ifdefs in the code. That wants to be a separate patch which also > cleans up the existing call sites. > > Thanks, > > tglx I will send patch v2 to solve all problems you listed. Thanks, --- David