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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 B7A15C433DF for ; Tue, 4 Aug 2020 12:52:07 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 371CD2075A for ; Tue, 4 Aug 2020 12:52:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="F8aZlF4L" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 371CD2075A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4BLZQY0DlgzDqYS for ; Tue, 4 Aug 2020 22:52:05 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=infradead.org (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org; envelope-from=peterz@infradead.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256 header.s=casper.20170209 header.b=F8aZlF4L; dkim-atps=neutral Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4BLZL63N1czDqPj for ; Tue, 4 Aug 2020 22:48:12 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vNu8jH7CfZCZghBH6Gb2x7F+2wKxDLAxRVOeoOs8VzY=; b=F8aZlF4L14jsBmodix7PwQGYqd V8/Xc9+OQR02QITvEpu+fYBjVFraifoNbS+FzDA2NNQuKy4emxGJLedIiZsESfiw/9laGnblINPhi fqXETQbpDJ2HAfdVQ7Z2DdtjubNTxnQLS5r4cPW34Q9wiFectjrncTdwTtDzNsCfjgo4nMcblkhNQ E3blt2fMkaCaqUpO/BrD8GLeuQVjCJ7Z0p9ClnLwWOGV2r06zj+xmn4rj7mTVFF+dBnEdHbUYiHvZ puSUzdXHYpfx4+ZBqTfYewnKWu6d4nQxpjIIpQ5AmLnIAgPnt+sRe494n84oRgs6Sm0L/AKd9DcUH FdlIUyzg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2wMH-0000WT-Ry; Tue, 04 Aug 2020 12:47:58 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id DBC9D301E02; Tue, 4 Aug 2020 14:47:55 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id A66B9235CDBD2; Tue, 4 Aug 2020 14:47:55 +0200 (CEST) Date: Tue, 4 Aug 2020 14:47:55 +0200 From: peterz@infradead.org To: Srikar Dronamraju Subject: Re: [PATCH 1/2] sched/topology: Allow archs to override cpu_smt_mask Message-ID: <20200804124755.GJ2674@hirez.programming.kicks-ass.net> References: <20200804033307.76111-1-srikar@linux.vnet.ibm.com> <20200804104520.GB2657@hirez.programming.kicks-ass.net> <20200804121007.GJ24375@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200804121007.GJ24375@linux.vnet.ibm.com> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Gautham R Shenoy , Michael Neuling , Vincent Guittot , Rik van Riel , linuxppc-dev , LKML , Ingo Molnar , Thomas Gleixner , Mel Gorman , Valentin Schneider , Dietmar Eggemann Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Aug 04, 2020 at 05:40:07PM +0530, Srikar Dronamraju wrote: > * peterz@infradead.org [2020-08-04 12:45:20]: > > > On Tue, Aug 04, 2020 at 09:03:06AM +0530, Srikar Dronamraju wrote: > > > cpu_smt_mask tracks topology_sibling_cpumask. This would be good for > > > most architectures. One of the users of cpu_smt_mask(), would be to > > > identify idle-cores. On Power9, a pair of cores can be presented by the > > > firmware as a big-core for backward compatibility reasons. > > > > > > In order to maintain userspace backward compatibility with previous > > > versions of processor, (since Power8 had SMT8 cores), Power9 onwards there > > > is option to the firmware to advertise a pair of SMT4 cores as a fused > > > cores (referred to as the big_core mode in the Linux Kernel). On Power9 > > > this pair shares the L2 cache as well. However, from the scheduler's point > > > of view, a core should be determined by SMT4. The load-balancer already > > > does this. Hence allow PowerPc architecture to override the default > > > cpu_smt_mask() to point to the SMT4 cores in a big_core mode. > > > > I'm utterly confused. > > > > Why can't you set your regular siblings mask to the smt4 thing? Who > > cares about the compat stuff, I thought that was an LPAR/AIX thing. > > There are no technical challenges to set the sibling mask to SMT4. > This is for Linux running on PowerVM. When these Power9 boxes are sold / > marketed as X core boxes (where X stand for SMT8 cores). Since on PowerVM > world, everything is in SMT8 mode, the device tree properties still mark > the system to be running on 8 thread core. There are a number of utilities > like ppc64_cpu that directly read from device-tree. They would get core > count and thread count which is SMT8 based. > > If the sibling_mask is set to small core, then same user when looking at FWIW, I find the small/big core naming utterly confusing vs the big/little naming from ARM. When you say small, I'm thinking of asymmetric cores, not SMT4/SMT8. > output from lscpu and other utilities that look at sysfs will start seeing > 2x number of cores to what he had provisioned and what the utilities from > the device-tree show. This can gets users confused. One will report SMT8 and the other SMT4, right? So only users that cannot read will be confused, but if you can't read, confusion is guaranteed anyway. Also, by exposing the true (SMT4) topology to userspace, userspace applications could behave better -- for those few that actually parse the topology information. > So to keep the device-tree properties, utilities depending on device-tree, > sysfs and utilities depending on sysfs on the same page, userspace are only > exposed as SMT8. I'm not convinced it makes sense to lie to userspace just to accomodate a few users that cannot read.