Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp983636ybh; Mon, 13 Jul 2020 06:31:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx6Y9CwKlX/NqnTnAkiCVp4x8vfMFwRDDY4MdRkL8DSaXdpXvU7uuk4inva8BGukULJy65/ X-Received: by 2002:a50:8adb:: with SMTP id k27mr88458170edk.267.1594647062788; Mon, 13 Jul 2020 06:31:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594647062; cv=none; d=google.com; s=arc-20160816; b=uceCDKNo4Bc68sad4QqCgbMid2MWHeGyLtA6Lrm+kobKoWlU4mCcQx1Z6nB822bzyS 6xFjcG3m9iF1zDNLyPCzEdtEyRD2XYVb471Z7OTZWV/vRgOiW3x4qkLmjohc6MFS6o2Z /Hf44O0RqnBgPxMqAa90PEvecnxTCCmIUlf3v0NJMxU6kvxxDZGpJJN8TqAzstlH4J4Z TdnrzgAXPIFo3ZqDZYTqswXEFiIzSdxik7sl4Af9/ampKhMKPdraKB4wRQkecGMAulh9 h3wfWj5dmMZh9Q0QpOGMQpa1R8ihL1LqFqOiExKJAB9dc6ufZzaCJyvyGvgcA+KNyd8P NN8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references; bh=lqksHxQGy2SzQhwt6FQUn8WNFumA/Fr/TION1MBPftU=; b=Puir5uI3Zrb3lxc9nBt8QSp8pPvs04UcZONtbfpROuRJWiahQzKdf8OvlZLD/IZuj9 62i/QUSQ6zF+VfpnDjK+P8WWLkPP1qO9QZhSkyI04IhZNHgOjAPdb2EXXuI2nKovtEkF r0qlGgeEqxWQcKm44tU3bcnfkh3/rl7tqzlOOsR1FkrJt7vpe+vHCRAM8fEBOPLb0+yY JKvvW24lhlfJR3eMS6rcjpZ6dSdjOO0+o/s23X5S4ARETMLlBhmStsSCpW/OXGspDDWG nbuGWoW1ITQ8t7yYGSdtRcng41l0KuVkXVWOZ64pvUYqiRkCEKlKYABsSBw0zht2vIWi J43A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w6si9099116eja.471.2020.07.13.06.30.39; Mon, 13 Jul 2020 06:31:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729756AbgGMN2d (ORCPT + 99 others); Mon, 13 Jul 2020 09:28:33 -0400 Received: from foss.arm.com ([217.140.110.172]:34816 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729649AbgGMN2d (ORCPT ); Mon, 13 Jul 2020 09:28:33 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 74A2430E; Mon, 13 Jul 2020 06:28:32 -0700 (PDT) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8B6773F7C3; Mon, 13 Jul 2020 06:28:31 -0700 (PDT) References: <20200701190656.10126-1-valentin.schneider@arm.com> <20200701190656.10126-8-valentin.schneider@arm.com> <20200713125543.GJ10769@hirez.programming.kicks-ass.net> User-agent: mu4e 0.9.17; emacs 26.3 From: Valentin Schneider To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, morten.rasmussen@arm.com Subject: Re: [PATCH v3 7/7] sched/topology: Use prebuilt SD flag degeneration mask In-reply-to: <20200713125543.GJ10769@hirez.programming.kicks-ass.net> Date: Mon, 13 Jul 2020 14:28:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/07/20 13:55, Peter Zijlstra wrote: > On Wed, Jul 01, 2020 at 08:06:55PM +0100, Valentin Schneider wrote: >> Leverage SD_DEGENERATE_GROUPS_MASK in sd_degenerate() and >> sd_degenerate_parent(). >> >> Note that this changes sd_degenerate() somewhat: I'm using the negation of >> SD_DEGENERATE_GROUPS_MASK as the mask of flags not requiring groups, which >> is equivalent to: >> >> SD_WAKE_AFFINE | SD_SERIALIZE | SD_NUMA >> >> whereas the current mask for that is simply >> >> SD_WAKE_AFFINE >> >> I played with a few toy NUMA topologies on QEMU and couldn't cause a >> different degeneration than what mainline does currently. If that is deemed >> too risky, we can go back to using SD_WAKE_AFFINE explicitly. > > Arguably SD_SERIALIZE needs groups, note how we're only having that > effective for machines with at least 2 nodes. It's a bit shit how we end > up there, but IIRC that's what it ends up as. > Right, AFAICT we get SD_SERIALIZE wherever we have SD_NUMA, which is any level above NODE. > SD_NUMA is descriptive, and not marking a group as degenerates because > it has SD_NUMA seems a bit silly. It does, although we can still degenerate it, see below. > But then, it would be the top domain > and would survive anyway? So from what I've tested we still get rid of those via sd_parent_degenerate(): child and parent have the same flags and same span, so parent goes out. That happens in the middle of the NUMA topology levels on that borked topology with weird distances, aka node distances: node 0 1 2 3 0: 10 12 20 22 1: 12 10 22 24 2: 20 22 10 12 3: 22 24 12 10 which ought to look something like (+local distance to end result) 2 10 2 1 <---> 0 <---> 2 <---> 3 We end up with the following NUMA levels (i.e. deduplicated distances) NUMA (<= 12) NUMA (<= 20) NUMA (<= 22) NUMA (<= 24) For e.g. any CPU of node1, NUMA(<=20) is gonna have the same span as NUMA(<=12), so we'll degenerate it.