Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp2935636pxf; Sun, 21 Mar 2021 12:05:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCU8cF8B00hLQRPQySC5oPV+NdznbLEKPvZ2JbVlWa8K+82RhL5skNjPWh14bfdWzwRZJx X-Received: by 2002:a17:907:3e9e:: with SMTP id hs30mr15979196ejc.66.1616353553260; Sun, 21 Mar 2021 12:05:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616353553; cv=none; d=google.com; s=arc-20160816; b=jS3XTyF+JYjeXrX49oaU0Z++n2TC5ABcxg25rLCNXs51ek3Imv+BXbZs2u3AgjK6+G yDAuIs/P0dEP8RSE9qsMAo371p9K6W163Z50Y3MLGavjacie909tjrLMfgPbGDG4oHIG +dgectkrR+XHd1wsgDszDMITg5SHsNQcCiD7dAJCcwGcG7mzScisMDDEvOEFQjm+xCIP B5FUd/bAPlR4pSvpPU25yMJu7+Lie9da/GAADm7Le21dNF8G2xt6gjwG7xBQ3HSXgU88 jLemrhn5lb+Y65Ch2w3t8zOCv6uIxutNT0HIHiWscnH6aCT8cBEDua4s5jNxnDvG+CqG C9cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:subject:cc:to:from:date; bh=yo2oaBXW/Z304mhPBPKesn+USofQF11Kj1pWIPlGKTQ=; b=ftbRxRyIcfJM0+oaBJJPimgDj7suSA7DmutXDtOggkvIckpvu6KqlEWXFIFJn5CP5O k2LGfuCEUVuRnR43GRcHYQetZrmxL1Itl+/5PF4i16zGHkR69rZkqp+i7NPjYS9Bdgyw /v6mg6A+ik7LfbAAvxrgGP9UHMs2UXFh8qBWORDLr6TjzcaAjYlbMLufUrjpp7udsCc2 EzNHdFtLhI8jm+fWV2ZhzHlbc9kGUpdAp8ccqVdJziyvnIFPJLkZAFwuIzgpwe9Ej6U2 fb8nXeKKnbl7ckKVdGjYHWL0lAbKeLbrRXut5PIvSvvmFNBzwI+h084Rrx1Is+GoU2uQ g6dQ== 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 m17si9191205edd.122.2021.03.21.12.05.30; Sun, 21 Mar 2021 12:05:53 -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 S230179AbhCUTEP (ORCPT + 99 others); Sun, 21 Mar 2021 15:04:15 -0400 Received: from shelob.surriel.com ([96.67.55.147]:33650 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230241AbhCUTEH (ORCPT ); Sun, 21 Mar 2021 15:04:07 -0400 Received: from [2603:3005:d05:2b00:6e0b:84ff:fee2:98bb] (helo=imladris.surriel.com) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lO3Ml-0000zB-AC; Sun, 21 Mar 2021 15:03:59 -0400 Date: Sun, 21 Mar 2021 15:03:58 -0400 From: Rik van Riel To: Mel Gorman Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com, "Peter Zijlstra (Intel)" , Ingo Molnar , Vincent Guittot , Valentin Schneider Subject: [PATCH v2] sched/fair: bring back select_idle_smt, but differently Message-ID: <20210321150358.71ef52b1@imladris.surriel.com> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: riel@shelob.surriel.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mel Gorman did some nice work in 9fe1f127b913 ("sched/fair: Merge select_idle_core/cpu()"), resulting in the kernel being more efficient at finding an idle CPU, and in tasks spending less time waiting to be run, both according to the schedstats run_delay numbers, and according to measured application latencies. Yay. The flip side of this is that we see more task migrations (about 30% more), higher cache misses, higher memory bandwidth utilization, and higher CPU use, for the same number of requests/second. This is most pronounced on a memcache type workload, which saw a consistent 1-3% increase in total CPU use on the system, due to those increased task migrations leading to higher L2 cache miss numbers, and higher memory utilization. The exclusive L3 cache on Skylake does us no favors there. On our web serving workload, that effect is usually negligible, but occasionally as large as a 9% regression in the number of requests served, due to some interaction between scheduler latency and the web load balancer. It appears that the increased number of CPU migrations is generally a good thing, since it leads to lower cpu_delay numbers, reflecting the fact that tasks get to run faster. However, the reduced locality and the corresponding increase in L2 cache misses hurts a little. The patch below appears to fix the regression, while keeping the benefit of the lower cpu_delay numbers, by reintroducing select_idle_smt with a twist: when a socket has no idle cores, check to see if the sibling of "prev" is idle, before searching all the other CPUs. This fixes both the occasional 9% regression on the web serving workload, and the continuous 2% CPU use regression on the memcache type workload. With Mel's patches and this patch together, the p95 and p99 response times for the memcache type application improve by about 20% over what they were before Mel's patches got merged. Signed-off-by: Rik van Riel diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 794c2cb945f8..0c986972f4cd 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6098,6 +6098,28 @@ static int select_idle_core(struct task_struct *p, int core, struct cpumask *cpu return -1; } +/* + * Scan the local SMT mask for idle CPUs. + */ +static int select_idle_smt(struct task_struct *p, struct sched_domain *sd, int +target) +{ + int cpu; + + if (!static_branch_likely(&sched_smt_present)) + return -1; + + for_each_cpu(cpu, cpu_smt_mask(target)) { + if (!cpumask_test_cpu(cpu, p->cpus_ptr) || + !cpumask_test_cpu(cpu, sched_domain_span(sd))) + continue; + if (available_idle_cpu(cpu) || sched_idle_cpu(cpu)) + return cpu; + } + + return -1; +} + #else /* CONFIG_SCHED_SMT */ static inline void set_idle_cores(int cpu, int val) @@ -6114,6 +6136,11 @@ static inline int select_idle_core(struct task_struct *p, int core, struct cpuma return __select_idle_cpu(core); } +static inline int select_idle_smt(struct task_struct *p, struct sched_domain *sd, int target) +{ + return -1; +} + #endif /* CONFIG_SCHED_SMT */ /* @@ -6121,7 +6148,7 @@ static inline int select_idle_core(struct task_struct *p, int core, struct cpuma * comparing the average scan cost (tracked in sd->avg_scan_cost) against the * average idle time for this rq (as found in rq->avg_idle). */ -static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int target) +static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int prev, int target) { struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask); int i, cpu, idle_cpu = -1, nr = INT_MAX; @@ -6155,6 +6182,13 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t time = cpu_clock(this); } + if (!smt && cpus_share_cache(prev, target)) { + /* No idle core. Check if prev has an idle sibling. */ + i = select_idle_smt(p, sd, prev); + if ((unsigned int)i < nr_cpumask_bits) + return i; + } + for_each_cpu_wrap(cpu, cpus, target) { if (smt) { i = select_idle_core(p, cpu, cpus, &idle_cpu); @@ -6307,7 +6341,7 @@ static int select_idle_sibling(struct task_struct *p, int prev, int target) if (!sd) return target; - i = select_idle_cpu(p, sd, target); + i = select_idle_cpu(p, sd, prev, target); if ((unsigned)i < nr_cpumask_bits) return i;