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 670183CBE97 for ; Wed, 22 Apr 2026 13:26:53 +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=1776864414; cv=none; b=SXNDI/VMBI7qLWHOdp2WzyV3sR5vQNCVZ1bdYCXTPXa4mAh9BuZrEuGdWOFMhdZAs1qB4gWTlJZOJwRbZccEsNNlfOJxSvHfH3UnLhggynEZIrTARpS25yAiQ576+w4e7jRkzQUkbtLubkGtiF3fnGWO+cECJnlRokjBn7yB5Ek= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776864414; c=relaxed/simple; bh=BC6BA7phf9QXxde0zTlmEZEZTU8fHcWJaPhKWlLARuE=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=n5sLsZyV9w8x/bSyKzJfail4gMWsXccfpTUR0QEGMnX/OO2YRBWAHcxiqubA1BVw52xsS8zikcFefg/OWW/gMkyAo8PFdF5M3mk6Db6hqS6gDb9pseKI/yRRCQgaWKayGG0apLZ6QUhY38vSZOVDCXVvqJ23rLZkAKYAPzq5g6I= 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=blCOqLiU; 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="blCOqLiU" 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 21FE51E2F; Wed, 22 Apr 2026 06:26:47 -0700 (PDT) Received: from [10.57.65.82] (unknown [10.57.65.82]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 09E123FBD2; Wed, 22 Apr 2026 06:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1776864412; bh=BC6BA7phf9QXxde0zTlmEZEZTU8fHcWJaPhKWlLARuE=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From; b=blCOqLiUmitYzNAtuuRmK5vthSGA26RpNP8NsPccAerlo14x/Iv3zYHFWaL3b5sN9 o+XjZub5yzUAeJB0f6rFU+wKTJfJJlmYSln/c2aMfldIAQXQTSdI92HQhwNyEJAQZF fM4SdQ/9tA1v9l+dCukITp38Ken4t6z062Nx3iOg= Message-ID: <8f71c69c-ddd6-4117-97ca-cefaa2a22180@arm.com> Date: Wed, 22 Apr 2026 15:26:49 +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 From: Dietmar Eggemann Subject: Re: [RFC PATCH] sched/fair: scale wake_wide() threshold by SMT width To: Zhang Qiao , Shrikanth Hegde Cc: tanghui20@huawei.com, Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org References: <20260407063915.2034198-1-zhangqiao22@huawei.com> <4276a8b7-141a-4e0b-bc35-47cb0a341801@linux.ibm.com> <45712e75-f27e-804a-940b-79e932452e6e@huawei.com> Content-Language: en-GB In-Reply-To: <45712e75-f27e-804a-940b-79e932452e6e@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 16.04.26 09:41, Zhang Qiao wrote: > Hi Shrikanth, > > 在 2026/4/8 1:58, Shrikanth Hegde 写道: >> Hi. >> >> On 4/7/26 12:09 PM, 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. >>> >> >> Isn't load balance to move it out? What does the workload do? > > The workload is a producer-consumer model: one producer wakes up ~50 > different consumers, with roughly 10+ consumers running concurrently. > The total number of tasks is well below the CPU count. But higher than your MC core count I believe? Otherwise you wouldn't care. I assume you have MC CPU count of 12-24. Do you have more than 2 different MCs. > In this scenario, load balancing is largely ineffective. Each consumer > spends most of its time sleeping, gets woken by the producer, runs > briefly to process the message, then goes back to sleep. There is > almost no window where a consumer sits on a CPU runqueue in the runnable > state waiting to be pulled. Since load balancing can only migrate > runnable tasks, it simply has no target to act on here. OK, but SD_BALANCE_WAKE is not set by default, nobody would experience a difference in behaviour on an SMT machine in terms of waking tasks wide, i.e. going through the slow path. Like I tried to explain in the adjacent thread, your wakees would only end up in the slow path in case your sched domains would have SD_BALANCE_WAKE set. Or do you just want to force wakeups which have wake_wide(p) return 1 always into the fast path with 'new_cpu == prev_cpu'? But this wouldn't be wake wide? [...]