Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp1516489pxy; Mon, 2 Aug 2021 03:46:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/cYhHc8iIaxJucVJobLKCW/5klcQxW1C5yUg9aysZWV/DcWqHHp4s4G0+xmJcMNh+IIys X-Received: by 2002:a02:c95a:: with SMTP id u26mr14538066jao.49.1627901219029; Mon, 02 Aug 2021 03:46:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627901219; cv=none; d=google.com; s=arc-20160816; b=SzfX/1p/wejeMmTVfGJgxSSLL2UT4E+hXnEXpZpXj8OUuPp6EwLmX9qI9JsWz3KtYt cDJjJdC2ZDi8RI5GOmKlxNufvN1I5PKh/DFxsaTjdHCAAxhZr3bP1iyb7hYlchZqV2E8 qOYTxTG3hJ2shVxkL9n+IyVl/pJq3HYsk5qaksWdTu9+yVO2WqyCAYkt/LxUzVhp9EYH Iuc+aErVDA6+IKaawSf/oOGvNGkd7UmllU8SBZPFv+8Y5IZidA634rOKOuhSkzrYZHTm mS0iZbWrV72htDVZ/pqkwcQ39qHLwYFAjOW6iUrn90t++lKXOzBgu/d+fJ7VxVwIm1X5 trQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-language:accept-language:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=68r88gKikVSaZOaZLN6yW6cqoqg7eN8VXdkjmC/JKo0=; b=ou+UDybbjKQNoeBrPliqnlxV6XuWsjbMEm82OFhZDmylFEJ0OJLPyz/sg6sQcxnZJh eh9GNAsQNDberYJ53s95pE/IiQM1ybdcmRwqZ/ffIQiq6aGkBTJQYb0E/caitLCvtntq sGmBCOtBLoeiwCcwtJ2Rqt1we2ndkk0QCXkdS1eg1mMQ7puiLoDU5abQkg68DUwMYaL1 32LFcdkXN+eIUbywbrm4pkNsMlw2/XKdphFrGbgxG6Xs4IkGHsrz7LANawCMluOmiauh TNCSH31vQzTevPzEG13mRLf+zF6Gv0/LqiSomA4EZm0ushwxHMuJ85gLlbldP/Jp6bGh rWIQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hisilicon.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t13si11457518ilg.9.2021.08.02.03.46.47; Mon, 02 Aug 2021 03:46:59 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hisilicon.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233213AbhHBKpI convert rfc822-to-8bit (ORCPT + 99 others); Mon, 2 Aug 2021 06:45:08 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:7914 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233167AbhHBKpH (ORCPT ); Mon, 2 Aug 2021 06:45:07 -0400 Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4GdZKv1czSz82xy; Mon, 2 Aug 2021 18:41:07 +0800 (CST) Received: from dggema771-chm.china.huawei.com (10.1.198.213) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Mon, 2 Aug 2021 18:44:56 +0800 Received: from dggemi761-chm.china.huawei.com (10.1.198.147) by dggema771-chm.china.huawei.com (10.1.198.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Mon, 2 Aug 2021 18:44:56 +0800 Received: from dggemi761-chm.china.huawei.com ([10.9.49.202]) by dggemi761-chm.china.huawei.com ([10.9.49.202]) with mapi id 15.01.2176.012; Mon, 2 Aug 2021 18:44:56 +0800 From: "Song Bao Hua (Barry Song)" To: Mel Gorman , LKML CC: Ingo Molnar , Peter Zijlstra , Vincent Guittot , Valentin Schneider , Aubrey Li , yangyicong Subject: RE: [PATCH 7/9] sched/fair: Thread-Topic: [PATCH 7/9] sched/fair: Thread-Index: AdeHithpk+6MoH1nReOqdrhhcPaNRwAAAg3A Date: Mon, 2 Aug 2021 10:44:56 +0000 Message-ID: <15338f545c08409eb4b73af9c5d7d5aa@hisilicon.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.201.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Mel Gorman [mailto:mgorman@techsingularity.net] > Sent: Monday, July 26, 2021 10:23 PM > To: LKML > Cc: Ingo Molnar ; Peter Zijlstra ; > Vincent Guittot ; Valentin Schneider > ; Aubrey Li ; Mel > Gorman > Subject: [PATCH 7/9] sched/fair: > > When scanning for a single CPU, the scan is limited based on the estimated > average idle time for a domain to reduce the risk that more time is spent > scanning for idle CPUs than we are idle for. > > With SMT, if an idle core is expected to exist there is no scan depth > limits so the scan depth may or may not be related to average idle time. > Unfortunately has_idle_cores can be very inaccurate when workloads are > rapidly entering/exiting idle (e.g. hackbench). > > As the scan depth is now proportional to cores and not CPUs, enforce > SIS_PROP for idle core scans. > > The performance impact of this is variable and is neither a universal > gain nor loss. In some cases, has_idle_cores will be cleared prematurely > because the whole domain was not scanned but has_idle_cores is already > known to be an inaccurate heuristic. There is also additional cost because > time calculations are made even for an idle core scan and the delta is > calculated for both scan successes and failures. Finally, SMT siblings > may be used prematurely due to scan depth limitations. > > On the flip side, scan depth is now consistent for both core and smt > scans. The reduction in scan depth improves performance in some cases > and wakeup latency is reduced in some cases. > > There were few changes identified in the SIS statistics but notably, > "SIS Core Hit" was slightly reduced in tbench as thread counts increased, > presumably due to the core search depth being throttled. > > Signed-off-by: Mel Gorman > --- > kernel/sched/fair.c | 33 +++++++++++++++++++-------------- > 1 file changed, 19 insertions(+), 14 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 20b9255ebf97..b180205e6b25 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -6232,7 +6232,7 @@ static int select_idle_cpu(struct task_struct *p, struct > sched_domain *sd, bool > > cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr); > > - if (sched_feat(SIS_PROP) && !has_idle_core) { > + if (sched_feat(SIS_PROP)) { > u64 avg_cost, avg_idle, span_avg; > unsigned long now = jiffies; > > @@ -6265,30 +6265,35 @@ static int select_idle_cpu(struct task_struct *p, struct > sched_domain *sd, bool > if (has_idle_core) { > i = select_idle_core(p, cpu, cpus, &idle_cpu); > if ((unsigned int)i < nr_cpumask_bits) > - return i; > + break; > > + nr -= sched_smt_weight; > } else { > - if (!--nr) > - return -1; > idle_cpu = __select_idle_cpu(cpu, p); > if ((unsigned int)idle_cpu < nr_cpumask_bits) > break; > + nr--; > } > + > + if (nr < 0) > + break; > } > > - if (has_idle_core) > - set_idle_cores(target, false); > + if ((unsigned int)idle_cpu < nr_cpumask_bits) { > + if (has_idle_core) > + set_idle_cores(target, false); For example, if we have 16 cpus(8 SMT2 cores). In case core7 is idle, we only have scanned core0+core1(cpu0-cpu3) and if these two cores are not idle, but here we set has_idle_cores to false while core7 is idle. It seems incorrect. > > - if (sched_feat(SIS_PROP) && !has_idle_core) { > - time = cpu_clock(this) - time; > + if (sched_feat(SIS_PROP)) { > + time = cpu_clock(this) - time; > > - /* > - * Account for the scan cost of wakeups against the average > - * idle time. > - */ > - this_rq->wake_avg_idle -= min(this_rq->wake_avg_idle, time); > + /* > + * Account for the scan cost of wakeups against the average > + * idle time. > + */ > + this_rq->wake_avg_idle -= min(this_rq->wake_avg_idle, time); > > - update_avg(&this_sd->avg_scan_cost, time); > + update_avg(&this_sd->avg_scan_cost, time); > + } > } > > return idle_cpu; > -- > 2.26.2 Thanks Barry