From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60A1EC433DB for ; Fri, 19 Mar 2021 10:04:53 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B1A8564E1F for ; Fri, 19 Mar 2021 10:04:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B1A8564E1F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UMGSLZUKOVe/yB0iSKLJ3l0zrcaT93BIwdxkG/BsCxI=; b=bbp0dXdUeoikczWhbRAjivgpc 1CbvX54TCmU9BkakFgKotInBK7Wh/tRf0IMBUAnIwh55Jesl2uc+CSpf0Mu31lhOkOKq0MGx6p1WM C5jJp1nBLXakHfFcVleGiLOgo8eCEbzF/tWclXaKsmV+FOwlIda4pqLwHBZYqWXBTtPuIos5zdlX2 8CP961dSNEtGSqxt+hGskuE/ugEXKrcvOTLc4wfJonQVvB7Ac0Z2H5PrpeEJAf3sPFdejU71cH9ON dGCby3ywV/HBZAv+NUOL5G4hJQkoNoSJvrXEwSiSlXtSsMByBSld7G854ZRsm5vrzwPdnlt7BIbq9 UDm0TQPrA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lNBxt-0070NI-77; Fri, 19 Mar 2021 10:02:45 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lNBx9-00707Y-Rv for linux-arm-kernel@lists.infradead.org; Fri, 19 Mar 2021 10:02:02 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id B60D364F1F; Fri, 19 Mar 2021 10:01:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1616148118; bh=XLFDw8khS5R5XbbGs996WELjZyr175WNcs5UdIpfIRA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ueZ4Ty00UOKcVmirgOXqQUSiDvralM+0rUWatVk2a6TKRdWzI4NWLPla+quPZlVim lQ1GojFfcyLcAO/7y63S1W6u7dCVAF2nbLg/lKBhpD5t6qYDjXAQAiK3JS3CZd2TKO aCuNII3U/lwcqrgmkX8rp/MfjEcEs58CNzI97jdU= Date: Fri, 19 Mar 2021 11:01:55 +0100 From: Greg KH To: Jonathan Cameron Cc: "Song Bao Hua (Barry Song)" , "tim.c.chen@linux.intel.com" , "catalin.marinas@arm.com" , "will@kernel.org" , "rjw@rjwysocki.net" , "vincent.guittot@linaro.org" , "bp@alien8.de" , "tglx@linutronix.de" , "mingo@redhat.com" , "lenb@kernel.org" , "peterz@infradead.org" , "dietmar.eggemann@arm.com" , "rostedt@goodmis.org" , "bsegall@google.com" , "mgorman@suse.de" , "msys.mizuma@gmail.com" , "valentin.schneider@arm.com" , "juri.lelli@redhat.com" , "mark.rutland@arm.com" , "sudeep.holla@arm.com" , "aubrey.li@linux.intel.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "x86@kernel.org" , "xuwei (O)" , "Zengtao (B)" , "guodong.xu@linaro.org" , yangyicong , "Liguozhu (Kenneth)" , "linuxarm@openeuler.org" , "hpa@zytor.com" Subject: Re: [RFC PATCH v5 1/4] topology: Represent clusters of CPUs within a die Message-ID: References: <20210319041618.14316-1-song.bao.hua@hisilicon.com> <20210319041618.14316-2-song.bao.hua@hisilicon.com> <20210319093616.00001879@Huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210319093616.00001879@Huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210319_100200_335085_C6B756B2 X-CRM114-Status: GOOD ( 31.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Mar 19, 2021 at 09:36:16AM +0000, Jonathan Cameron wrote: > On Fri, 19 Mar 2021 06:57:08 +0000 > "Song Bao Hua (Barry Song)" wrote: > > > > -----Original Message----- > > > From: Greg KH [mailto:gregkh@linuxfoundation.org] > > > Sent: Friday, March 19, 2021 7:35 PM > > > To: Song Bao Hua (Barry Song) > > > Cc: tim.c.chen@linux.intel.com; catalin.marinas@arm.com; will@kernel.org; > > > rjw@rjwysocki.net; vincent.guittot@linaro.org; bp@alien8.de; > > > tglx@linutronix.de; mingo@redhat.com; lenb@kernel.org; peterz@infradead.org; > > > dietmar.eggemann@arm.com; rostedt@goodmis.org; bsegall@google.com; > > > mgorman@suse.de; msys.mizuma@gmail.com; valentin.schneider@arm.com; Jonathan > > > Cameron ; juri.lelli@redhat.com; > > > mark.rutland@arm.com; sudeep.holla@arm.com; aubrey.li@linux.intel.com; > > > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > > > linux-acpi@vger.kernel.org; x86@kernel.org; xuwei (O) ; > > > Zengtao (B) ; guodong.xu@linaro.org; yangyicong > > > ; Liguozhu (Kenneth) ; > > > linuxarm@openeuler.org; hpa@zytor.com > > > Subject: Re: [RFC PATCH v5 1/4] topology: Represent clusters of CPUs within > > > a die > > > > > > On Fri, Mar 19, 2021 at 05:16:15PM +1300, Barry Song wrote: > > > > diff --git a/Documentation/admin-guide/cputopology.rst > > > b/Documentation/admin-guide/cputopology.rst > > > > index b90dafc..f9d3745 100644 > > > > --- a/Documentation/admin-guide/cputopology.rst > > > > +++ b/Documentation/admin-guide/cputopology.rst > > > > @@ -24,6 +24,12 @@ core_id: > > > > identifier (rather than the kernel's). The actual value is > > > > architecture and platform dependent. > > > > > > > > +cluster_id: > > > > + > > > > + the Cluster ID of cpuX. Typically it is the hardware platform's > > > > + identifier (rather than the kernel's). The actual value is > > > > + architecture and platform dependent. > > > > + > > > > book_id: > > > > > > > > the book ID of cpuX. Typically it is the hardware platform's > > > > @@ -56,6 +62,14 @@ package_cpus_list: > > > > human-readable list of CPUs sharing the same physical_package_id. > > > > (deprecated name: "core_siblings_list") > > > > > > > > +cluster_cpus: > > > > + > > > > + internal kernel map of CPUs within the same cluster. > > > > + > > > > +cluster_cpus_list: > > > > + > > > > + human-readable list of CPUs within the same cluster. > > > > + > > > > die_cpus: > > > > > > > > internal kernel map of CPUs within the same die. > > > > > > Why are these sysfs files in this file, and not in a Documentation/ABI/ > > > file which can be correctly parsed and shown to userspace? > > > > Well. Those ABIs have been there for much a long time. It is like: > > > > [root@ceph1 topology]# ls > > core_id core_siblings core_siblings_list physical_package_id thread_siblings thread_siblings_list > > [root@ceph1 topology]# pwd > > /sys/devices/system/cpu/cpu100/topology > > [root@ceph1 topology]# cat core_siblings_list > > 64-127 > > [root@ceph1 topology]# > > > > > > > > Any chance you can fix that up here as well? > > > > Yes. we will send a separate patch to address this, which won't > > be in this patchset. This patchset will base on that one. > > > > > > > > Also note that "list" is not something that goes in sysfs, sysfs is "one > > > value per file", and a list is not "one value". How do you prevent > > > overflowing the buffer of the sysfs file if you have a "list"? > > > > > > > At a glance, the list is using "-" rather than a real list > > [root@ceph1 topology]# cat core_siblings_list > > 64-127 > > > > Anyway, I will take a look if it has any chance to overflow. > > It could in theory be alternate CPUs as comma separated list. > So it's would get interesting around 500-1000 cpus (guessing). > > Hopefully no one has that crazy a cpu numbering scheme but it's possible > (note that cluster is fine for this, but I guess it might eventually > happen for core-siblings list (cpus within a package). > > Shouldn't crash or anything like that but might terminate early. We have a broken sysfs api already for listing LED numbers that has had to be worked around in the past, please do not create a new one with that same problem, we should learn from them :) thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel