From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 19447226CFE for ; Tue, 7 Apr 2026 14:38:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775572708; cv=none; b=UEH6uRiDCExWTM/07ZAfZzyuj7HiDg2KRE5A26PgEsvrZHymQjkHuREC+RyHhoBZE21HYTY0C9goXpWKBE0Eqglitrj9U4K5PF7gG2/MKfcWJoSlsMDD1BwsgqtTSwuDB3T6mJZ21hHuMA4Ju9wuHFv9rlbtNYI4nVk+nx3JHwo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775572708; c=relaxed/simple; bh=pflvxnBWRR2mqRBaloZ5EyweYTAwtpYYvBfMC61J4Hc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bzuI9Sl4oGWZwL2o65NBEZ0E01NRe4I/Cs7ra2K9wvJmTWi8/fvwf0d+rEyYVuQbRczNU44SdPfHD/GUdXYeWsquma+qFr+omErSdF4Opn1FHhjXar14o9RjctMFaQfam5dldchJO+sTq3SxhFNmx4R/cq/1/oFOSB79Yq/QKO4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=nz/v15W5; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="nz/v15W5" 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 873D41A00; Tue, 7 Apr 2026 07:38:19 -0700 (PDT) Received: from [192.168.178.6] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4E2633F641; Tue, 7 Apr 2026 07:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1775572705; bh=pflvxnBWRR2mqRBaloZ5EyweYTAwtpYYvBfMC61J4Hc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=nz/v15W5Uf/zQU5cxsKxwZvyKH+2CzbHULkhBykIrKVTZee0aLldSIprnhwzBVpN2 W4xJpmD3yVnOZee8HqYhSE7FNUnfA3SbNFjjk3uo7fNarLnjT78aoFfLKAcACWDF9+ AheWf1lswW3mF1PFGGn/tyK22ruTRyvVPvnxmgV0= Message-ID: <0aca0ee5-4102-426e-b290-6c50b6e819a7@arm.com> Date: Tue, 7 Apr 2026 16:38:21 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] sched/fair: scale wake_wide() threshold by SMT width To: Zhang Qiao , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org Cc: tanghui20@huawei.com References: <20260407063915.2034198-1-zhangqiao22@huawei.com> Content-Language: en-GB From: Dietmar Eggemann In-Reply-To: <20260407063915.2034198-1-zhangqiao22@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07.04.26 08:39, Zhang Qiao wrote: > wake_wide() uses sd_llc_size as the spreading threshold to detect wide > waker/wakee relationships and to disable wake_affine() for those cases. > > On SMT systems, sd_llc_size counts logical CPUs rather than physical > cores. This inflates the wake_wide() threshold, allowing wake_affine() > to pack more tasks into one LLC domain than the actual compute capacity > of its physical cores can sustain. The resulting SMT interference may > cost more than the cache-locality benefit wake_affine() intends to gain. > > Scale the factor by the SMT width of the current CPU so that it > approximates the number of independent physical cores in the LLC domain, > making wake_wide() more likely to kick in before SMT interference > becomes significant. On non-SMT systems the SMT width is 1 and behaviour > is unchanged. > > Signed-off-by: Zhang Qiao > --- > kernel/sched/fair.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index f07df8987a5ef..4896582c6e904 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -7334,6 +7334,11 @@ static int wake_wide(struct task_struct *p) > unsigned int slave = p->wakee_flips; > int factor = __this_cpu_read(sd_llc_size); > > + /* Scale factor to physical-core count to account for SMT interference. */ > + if (sched_smt_active()) > + factor = DIV_ROUND_UP(factor, > + cpumask_weight(cpu_smt_mask(smp_processor_id()))); > + > if (master < slave) > swap(master, slave); > if (slave < factor || master < slave * factor) I assume not a lot of people care since this needs: diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 5847b83d9d55..596c5d590532 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -1691,7 +1691,7 @@ sd_init(struct sched_domain_topology_level *tl, .flags = 1*SD_BALANCE_NEWIDLE | 1*SD_BALANCE_EXEC | 1*SD_BALANCE_FORK - | 0*SD_BALANCE_WAKE + | 1*SD_BALANCE_WAKE | 1*SD_WAKE_AFFINE | 0*SD_SHARE_CPUCAPACITY | 0*SD_SHARE_LLC And then it's a trade-off between one busy thread per core vs. wakeup cost.