Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp1713059ybd; Wed, 26 Jun 2019 23:56:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqyI1+rgsaqZ8Na1CJGqBEZqNRGpW8KDmeueyRjkB06KoqvGCqrUxtuogSI8d4YgA3mOpE/8 X-Received: by 2002:a65:6686:: with SMTP id b6mr2236818pgw.125.1561618618173; Wed, 26 Jun 2019 23:56:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561618618; cv=none; d=google.com; s=arc-20160816; b=VbX+eFZgWQfuCuSefylN74NkMAVIMisrvYPea4P7UO1f39sReIx1uzkhg7RdifAfwL +THW2S1XjP4kG2d5UTuhreaEySB5/Zrk3ibBr+R9bbWRmQrfc9AG6e3FDuW7sSxRc0pn //yMrerVeuLJM0XJsEoVGqnvU2gCq/SPExHnVsvyAutiSzC4UtmXxXKHjb6bvavCYC/p mKAkggoMIc6Fyy2NEm3kd+WpFzFlxshxWvOV1x1S+t5LD9x/omkh8Tm/zV7XERNqlTl3 6HcUukM9aKTeXxKRy7aWni/bNhVHhLKm75cRAdXjQcZOHvJc6XUheAmu0psaH+UnfxLi r+Ag== 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; bh=AyfGi2rLJXH1l/+/1yNOnivmermZjhrezN9O2hQl2Hk=; b=QYabLg59T/c2jI0YNxnRWR9aA54w404v8cB3VysV3sdrI3kQLcUinxqyKVQEqw1JVI XMeTSuvnzKEFDaZFj32UtefGhh95K6w72ga0Ylz/5081AzBF7qftBZJJz6uZrpPJvq/T 5gQqtB4CQgDi8LLFnv8NKgo5b2swaBYSI9juBFNO1TGxwDopnBsp/yQzKJb3f2I5SP66 3iY0W6DNR3sxpn7in1WGRGMv3sLmbTlWZAOSwmwWiWpOMUbpd57pHzPyLRm1q7c5ajqR XbtOb+dBpK/aMjeqPg9dUimm47Fxl051M+JDUsTt9nu7Xb6D2Ygf89xznUZjWYUrsM+S R/8Q== 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 k1si1388698pgo.574.2019.06.26.23.56.41; Wed, 26 Jun 2019 23:56:58 -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 S1726476AbfF0Gyw (ORCPT + 99 others); Thu, 27 Jun 2019 02:54:52 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:52482 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726443AbfF0Gyw (ORCPT ); Thu, 27 Jun 2019 02:54:52 -0400 Received: from p5b06daab.dip0.t-ipconnect.de ([91.6.218.171] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hgOJ0-0003EC-4Y; Thu, 27 Jun 2019 08:54:50 +0200 Date: Thu, 27 Jun 2019 08:54:49 +0200 (CEST) From: Thomas Gleixner To: subhra mazumdar cc: linux-kernel@vger.kernel.org, peterz@infradead.org, mingo@redhat.com, steven.sistare@oracle.com, dhaval.giani@oracle.com, daniel.lezcano@linaro.org, vincent.guittot@linaro.org, viresh.kumar@linaro.org, tim.c.chen@linux.intel.com, mgorman@techsingularity.net Subject: Re: [PATCH v3 6/7] x86/smpboot: introduce per-cpu variable for HT siblings In-Reply-To: Message-ID: References: <20190627012919.4341-1-subhra.mazumdar@oracle.com> <20190627012919.4341-7-subhra.mazumdar@oracle.com> 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 Thu, 27 Jun 2019, Thomas Gleixner wrote: > On Wed, 26 Jun 2019, subhra mazumdar wrote: > > > Introduce a per-cpu variable to keep the number of HT siblings of a cpu. > > This will be used for quick lookup in select_idle_cpu to determine the > > limits of search. > > Why? The number of siblings is constant at least today unless you play > silly cpu hotplug games. A bit more justification for adding yet another > random storage would be appreciated. > > > This patch does it only for x86. > > # grep 'This patch' Documentation/process/submitting-patches.rst > > IOW, we all know already that this is a patch and from the subject prefix > and the diffstat it's pretty obvious that this is x86 only. > > So instead of documenting the obvious, please add proper context to justify > the change. Aside of that the right ordering is to introduce the default fallback in a separate patch, which explains the reasoning and then in the next one add the x86 optimized version. Thanks, tglx