Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp930591pxb; Wed, 3 Mar 2021 21:29:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJzBW12Hx8E6j4FWMnQSHpZf2+7eb44f3ELkEy5SrevcGGFt9R09fUJw4FukTPQ5r7D649CK X-Received: by 2002:a17:906:5d06:: with SMTP id g6mr2414840ejt.216.1614835762672; Wed, 03 Mar 2021 21:29:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614835762; cv=none; d=google.com; s=arc-20160816; b=vCql/4kRcpmmX5KWrLCDILk1/XRcj+a3l+sGcXeveEpQP+UGH5M8P+HU0uzyA9pCqU EB0Bpt8lcb3Jt9DGseOJ9s8SJlLOw0RWL1c7bInOVndHEqaCv4wiphgLI61dIER8yY+B AhyHEYUxwpcGI5gP/ruc6LJkDBOUCm0h2qS0x3cljej1pqUkf6sBPpuL2MqbD+VgjDvQ D3HutjJA7aHCpoGSilX0WWirWfYXjXwYitDn42fdTUY6MAc/C0+S05aPA8Nkr0Lbbddn OTing5YrJjP1snQ3afjCUcSBk+P/+uDaekExifTxL/G77FWxVSr7vEQS4bBhhhSJL9ob 1WYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=ZXMdo/5OQ8uDFxWXH4mbnUKsDuujhKJEYvzG4W+ovzE=; b=FRVVpKbdwmaEPaXI1rRCT5f0outCulsKJkdiw/aRZDBq+JxgopUxmGilUBpQcoT04m dQVcdgHGqGVfg8F4NVI003LdGLUJxEV1y14qi/4Ev0lwvep7zgoYC0feuIdvvYCBHLkB j5p5U/wrGOHGpPT1uV/V+J4IycslKPWt/jx/ycf3Xl+2x6827P2Oa79wAZX9NydHkNHC kQeJlae++33B6Iq3VyeohpbYpihuwnKeFxbHXWyG3JJ5MuHdP43GaM3tCpQGvMI6soAg H+OpCWQtmM7C2fuhZ2JsxZJBWghk6ACT0M9IqTlAQWQbn5c1XBjA6JOh1+Mb3lP45rXp vYZA== 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 a14si12819380ejk.698.2021.03.03.21.29.00; Wed, 03 Mar 2021 21:29:22 -0800 (PST) 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 S1575523AbhCBD4e (ORCPT + 99 others); Mon, 1 Mar 2021 22:56:34 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:13014 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239132AbhCAXGw (ORCPT ); Mon, 1 Mar 2021 18:06:52 -0500 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4DqG6b5pxWzjThg; Tue, 2 Mar 2021 07:04:23 +0800 (CST) Received: from SWX921481.china.huawei.com (10.126.203.209) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.498.0; Tue, 2 Mar 2021 07:05:55 +0800 From: Barry Song To: , , , , , , , , , , , , , CC: , , , , , , , , , , , , , , , , , , , Barry Song Subject: [RFC PATCH v4 0/3] scheduler: expose the topology of clusters and add cluster scheduler Date: Tue, 2 Mar 2021 11:59:37 +1300 Message-ID: <20210301225940.16728-1-song.bao.hua@hisilicon.com> X-Mailer: git-send-email 2.21.0.windows.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.126.203.209] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ARM64 server chip Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each cluster has 4 cpus. All clusters share L3 cache data while each cluster has local L3 tag. On the other hand, each cluster will share some internal system bus. This means cache is much more affine inside one cluster than across clusters. +-----------------------------------+ +---------+ | +------+ +------+ +---------------------------+ | | | CPU0 | | cpu1 | | +-----------+ | | | +------+ +------+ | | | | | | +----+ L3 | | | | +------+ +------+ cluster | | tag | | | | | CPU2 | | CPU3 | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | | +-----------------------------------+ | | | +------+ +------+ +--------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | | | | L3 | | | | +------+ +------+ +----+ tag | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | L3 | | data | +-----------------------------------+ | | | +------+ +------+ | +-----------+ | | | | | | | | | | | | | +------+ +------+ +----+ L3 | | | | | | tag | | | | +------+ +------+ | | | | | | | | | | ++ +-----------+ | | | +------+ +------+ |---------------------------+ | +-----------------------------------| | | +-----------------------------------| | | | +------+ +------+ +---------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | | +----+ L3 | | | | +------+ +------+ | | tag | | | | | | | | | | | | | | +------+ +------+ | +-----------+ | | | | | | +-----------------------------------+ | | +-----------------------------------+ | | | +------+ +------+ +--------------------------+ | | | | | | | +-----------+ | | | +------+ +------+ | | | | | There is a similar need for clustering in x86. Some x86 cores could share L2 caches that is similar to the cluster in Kupeng 920 (e.g. on Jacobsville there are 6 clusters of 4 Atom cores, each cluster sharing a separate L2, and 24 cores sharing L3). Having a sched_domain for clusters will bring two aspects of improvement: 1. spreading unrelated tasks among clusters, which decreases the contention of resources and improve the throughput. unrelated tasks might be put randomly without cluster sched_domain: +-------------------+ +-----------------+ | +----+ +----+ | | | | |task| |task| | | | | |1 | |2 | | | | | +----+ +----+ | | | | | | | | cluster1 | | cluster2 | +-------------------+ +-----------------+ but with cluster sched_domain, they are likely to spread due to LB: +-------------------+ +-----------------+ | +----+ | | +----+ | | |task| | | |task| | | |1 | | | |2 | | | +----+ | | +----+ | | | | | | cluster1 | | cluster2 | +-------------------+ +-----------------+ 2. gathering related tasks within a cluster, which improves the cache affinity of tasks talking with each other. Without cluster sched_domain, related tasks might be put randomly. In case task1-8 have relationship as below: Task1 wakes up task4 Task2 wakes up task5 Task3 wakes up task6 Task4 wakes up task7 With the tuning of select_idle_cpu() to scan local cluster first, those tasks might get a chance to be gathered like: +---------------------------+ +----------------------+ | +----+ +-----+ | | +----+ +-----+ | | |task| |task | | | |task| |task | | | |1 | | 4 | | | |2 | |5 | | | +----+ +-----+ | | +----+ +-----+ | | | | | | cluster1 | | cluster2 | | | | | | | | | | +-----+ +------+ | | +-----+ +------+ | | |task | | task | | | |task | |task | | | |3 | | 6 | | | |4 | |8 | | | +-----+ +------+ | | +-----+ +------+ | +---------------------------+ +----------------------+ Otherwise, the result might be: +---------------------------+ +----------------------+ | +----+ +-----+ | | +----+ +-----+ | | |task| |task | | | |task| |task | | | |1 | | 2 | | | |5 | |6 | | | +----+ +-----+ | | +----+ +-----+ | | | | | | cluster1 | | cluster2 | | | | | | | | | | +-----+ +------+ | | +-----+ +------+ | | |task | | task | | | |task | |task | | | |3 | | 4 | | | |7 | |8 | | | +-----+ +------+ | | +-----+ +------+ | +---------------------------+ +----------------------+ -v4: * rebased to tip/sched/core with the latest unified code of select_idle_cpu * added Tim's patch for x86 Jacobsville * also added benchmark data of spreading unrelated tasks * avoided the iteration of sched_domain by moving to static_key(addressing Vincent's comment * used acpi_cpu_id for acpi_find_processor_node(addressing Masa's comment) Barry Song (1): scheduler: add scheduler level for clusters Jonathan Cameron (1): topology: Represent clusters of CPUs within a die. Tim Chen (1): scheduler: Add cluster scheduler level for x86 Documentation/admin-guide/cputopology.rst | 26 ++++++++++-- arch/arm64/Kconfig | 7 ++++ arch/arm64/kernel/topology.c | 2 + arch/x86/Kconfig | 8 ++++ arch/x86/include/asm/smp.h | 7 ++++ arch/x86/include/asm/topology.h | 1 + arch/x86/kernel/cpu/cacheinfo.c | 1 + arch/x86/kernel/cpu/common.c | 3 ++ arch/x86/kernel/smpboot.c | 43 +++++++++++++++++++- drivers/acpi/pptt.c | 63 +++++++++++++++++++++++++++++ drivers/base/arch_topology.c | 14 +++++++ drivers/base/topology.c | 10 +++++ include/linux/acpi.h | 5 +++ include/linux/arch_topology.h | 5 +++ include/linux/sched/cluster.h | 19 +++++++++ include/linux/sched/sd_flags.h | 9 +++++ include/linux/sched/topology.h | 7 ++++ include/linux/topology.h | 13 ++++++ kernel/sched/core.c | 18 +++++++++ kernel/sched/fair.c | 66 ++++++++++++++++++++++++------- kernel/sched/sched.h | 1 + kernel/sched/topology.c | 6 +++ 22 files changed, 315 insertions(+), 19 deletions(-) create mode 100644 include/linux/sched/cluster.h -- 1.8.3.1