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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 A1DEDC433E0 for ; Wed, 3 Feb 2021 11:44:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 496E464F72 for ; Wed, 3 Feb 2021 11:44:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234484AbhBCLno (ORCPT ); Wed, 3 Feb 2021 06:43:44 -0500 Received: from foss.arm.com ([217.140.110.172]:38472 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234467AbhBCLnK (ORCPT ); Wed, 3 Feb 2021 06:43:10 -0500 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 3A8E613D5; Wed, 3 Feb 2021 03:42:24 -0800 (PST) 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 7AC203F719; Wed, 3 Feb 2021 03:42:21 -0800 (PST) From: Valentin Schneider To: "Song Bao Hua \(Barry Song\)" , "vincent.guittot\@linaro.org" , "mgorman\@suse.de" , "mingo\@kernel.org" , "peterz\@infradead.org" , "dietmar.eggemann\@arm.com" , "morten.rasmussen\@arm.com" , "linux-kernel\@vger.kernel.org" Cc: "linuxarm\@openeuler.org" , "xuwei \(O\)" , "Liguozhu \(Kenneth\)" , "tiantao \(H\)" , wanghuiqiang , "Zengtao \(B\)" , Jonathan Cameron , "guodong.xu\@linaro.org" , Meelis Roos Subject: RE: [PATCH] sched/topology: fix the issue groups don't span domain->span for NUMA diameter > 2 In-Reply-To: <64209fc8849447e6bcd2d36e74a48fc3@hisilicon.com> References: <20210201033830.15040-1-song.bao.hua@hisilicon.com> <64209fc8849447e6bcd2d36e74a48fc3@hisilicon.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/26.3 (x86_64-pc-linux-gnu) Date: Wed, 03 Feb 2021 11:42:15 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/02/21 10:23, Song Bao Hua (Barry Song) wrote: >> -----Original Message----- >> From: Valentin Schneider [mailto:valentin.schneider@arm.com] >> Thoughts? > > I guess the original purpose of overlapping groups is creating as few groups > as possible. If we totally remove overlapping groups, it seems we will create > much more groups? > For example, while node0 begins to build sched_domain for distance 20, it will > add node2, since the distance between node2 and node3 is 15, so while node2 is > added, node3 is also added as node2's lower domain has covered node3. So we need > two groups only for node0's sched_domain of distance level 20. > +-------+ +--------+ > | | 15 | | > | node0+----------------+ | node1 | > | | | | > +----+--+ XXX--------+ > | XXX > | XX > 20 | 15 XX > | XXX > | X XXX > +----+----XXX +-------+ > | | 15 | node3| > | node2 +-----------------+ | > | | +-------+ > +---------+ > > If we remove overlapping group, we will add a group for node2, another > group for node3. Then we get three groups. > > I am not sure if it is always positive for performance. > Neither am I! At the same time our strategy for generating groups is pretty much flawed for anything with distance > 2, so I'd like to have a saner setup that doesn't involve fixing groups "after the fact". I have a sort-of-working hack, I'll make this into a patch and toss it out for discussion.