From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751852AbeDFJCq (ORCPT ); Fri, 6 Apr 2018 05:02:46 -0400 Received: from merlin.infradead.org ([205.233.59.134]:35112 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751746AbeDFJCo (ORCPT ); Fri, 6 Apr 2018 05:02:44 -0400 Date: Fri, 6 Apr 2018 11:02:28 +0200 From: Peter Zijlstra To: Dou Liyang Cc: Thomas Gleixner , Li RongQing , LKML Subject: Re: [PATCH] genirq: only scan the present CPUs Message-ID: <20180406090228.GI4082@hirez.programming.kicks-ass.net> References: <1522647902-11426-1-git-send-email-lirongqing@baidu.com> <20180403112311.GF4043@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 06, 2018 at 04:42:14PM +0800, Dou Liyang wrote: > Hi Thomas, Peter, > > At 04/03/2018 07:23 PM, Peter Zijlstra wrote: > > On Tue, Apr 03, 2018 at 12:25:56PM +0200, Thomas Gleixner wrote: > > > On Mon, 2 Apr 2018, Li RongQing wrote: > > > > > > > lots of application will read /proc/stat, like ps and vmstat, but we > > > > find the reading time are spreading on Purley platform which has lots > > > > of possible CPUs and interrupt. > > > > > > > > To reduce the reading time, only scan the present CPUs, not all possible > > > > CPUs, which speeds the reading of /proc/stat 20 times on Purley platform > > > > which has 56 present CPUs, and 224 possible CPUs > > > > > > Why is BIOS/ACPI telling the kernel that there are 224 possible CPUs unless > > > it supports physical CPU hotplug. > > > > BIOS is crap, news at 11. I've got boxes like that too. Use > > possible_cpu=$nr if you're bothered by it -- it's what I do. > > > > Yes, I think so. it is a manual way to reset the number. > > For this situation, I am investigating to restrict the number of > possible CPUs automatically, But, due to the limitation of ACPI > subsystem, I can do it _before_ setup_percpu_area where the number will > be used. > > But, I can provider an indicator to tell the system that whether the > physical CPU hotplug is support or not later. Can we use this indicator > like that in this situation: If anything you should fix up the enumeration; not random users after the fact. So if you see it enumerates a gazillion empty spots but the system does not in fact support physical hotplug, we should discard those.