From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout07.his.huawei.com (canpmsgout07.his.huawei.com [113.46.200.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9A7201F7541 for ; Sat, 28 Mar 2026 02:49:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.222 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774666153; cv=none; b=bHLD9pNqM+clo3q3nqteyHym9qZQ98IqqurBwvgTLqboS38b4+GK8AH3RPf5RAlcN/HWXDSOb/VroFOkOdvW61rsbA9uM3QMmu9JGkAUoZm2BQXmOimu0d6wLAIHtK61mPutr4NM+F724g4Z9T+dErCv/1dO/3cyyKvBzoujQ8g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774666153; c=relaxed/simple; bh=97okxLZirEM9QvxjxAbbKlgcb7vj90/F+P7X6Im9XMU=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=Dn9WwNIhFjrEJCxvMTFoeZ4Md1g743LoweX0czDI0Zb/AHxgLDW+3ljnfIsgPwJ1oLI64gD5qMS7FvlyIco/U0Ffl8RuibMwXw8YUdRJYoFvbmhB6lrMswgIG6B+rpv9QNGQprbWIjNtM7YWKQkygkT1Bx07ATm3T7nwUduQ0Co= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Bz3qwGSE; arc=none smtp.client-ip=113.46.200.222 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Bz3qwGSE" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=S/2uMKMxSyQN4tnhZtmIzX1fMjC2iF5N4bya2MjwkDs=; b=Bz3qwGSEAO8p85AO2RSL16HPHRRXzvR71B9bzNz7fKurLz72ksLlf4i7YSKoI5hirYH/8TvMd //B84aTGFcqmu2OJeoUkw88nHvOHuf4hCFVzIDjJcJh4jzEBEtZuJJwrWsH74FP1fWW/YGSGOrC ArRYyMGCbIRi5v6Y+nMVEx8= Received: from mail.maildlp.com (unknown [172.19.163.127]) by canpmsgout07.his.huawei.com (SkyGuard) with ESMTPS id 4fjMHy3WzLzLlXm; Sat, 28 Mar 2026 10:42:54 +0800 (CST) Received: from kwepemr500016.china.huawei.com (unknown [7.202.195.68]) by mail.maildlp.com (Postfix) with ESMTPS id E32EF40363; Sat, 28 Mar 2026 10:49:00 +0800 (CST) Received: from [10.67.111.161] (10.67.111.161) by kwepemr500016.china.huawei.com (7.202.195.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 28 Mar 2026 10:49:00 +0800 Message-ID: Date: Sat, 28 Mar 2026 10:48:59 +0800 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 v5 0/9] steal tasks to improve CPU utilization To: Peter Zijlstra CC: "mingo@redhat.com" , "juri.lelli@redhat.com" , "vincent.guittot@linaro.org" , "linux-kernel@vger.kernel.org" , "bsegall@google.com" , "dietmar.eggemann@arm.com" , "rostedt@goodmis.org" , "mgorman@suse.de" , "vschneid@redhat.com" , "kprateek.nayak@amd.com" , "chenl311@chinatelecom.cn" , "steve.sistare@oracle.com" References: <20260320055920.2518389-1-chenjinghuang2@huawei.com> <20260320085325.GM3738786@noisy.programming.kicks-ass.net> From: chenjinghuang In-Reply-To: <20260320085325.GM3738786@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To kwepemr500016.china.huawei.com (7.202.195.68) On 3/20/2026 4:53 PM, Peter Zijlstra wrote: > On Fri, Mar 20, 2026 at 05:59:11AM +0000, Chen Jinghuang wrote: >> When a CPU has no more CFS tasks to run, and idle_balance() fails to >> find a task, then attempt to steal a task from an overloaded CPU in the >> same LLC. Maintain and use a bitmap of overloaded CPUs to efficiently >> identify candidates. To minimize search time, steal the first migratable >> task that is found when the bitmap is traversed. For fairness, search >> for migratable tasks on an overloaded CPU in order of next to run. > > This makes no sense. It is the task of newidle to get more work -- if > that is failing for you, then we should fix that, not build a second way > to get tasks. > > > Hi Peter, That is a very valid point. However, profiling data indicates that newidle_balance() still incurs excessive scanning overhead. Sharing the expensive tick balance path is becoming an issue on high-core-count systems. As highlighted in recent ILB threads, profiling sqlite on a 224-CPU Sapphire Rapids shows: https://lore.kernel.org/all/cover.1690273854.git.yu.c.chen@intel.com/ 6.69% 0.09% sqlite3 [kernel.kallsyms] [k] newidle_balance 5.39% 4.71% sqlite3 [kernel.kallsyms] [k] update_sd_lb_stats Walking the sd hierarchy in update_sd_lb_stats alone consumes over 5% of CPU cycles. If we spend all that time scanning just to pull a tiny, short-lived task, the search overhead dwarfs the actual runtime. It's a net loss. To mitigate this cost, I'd like to check if you are open to these two directions: 1.Goal: As Tim questioned in the thread above: "Do we always have to find the busiest group and pull from it? Would a relatively busy group be enough?" Instead of chasing absolute fairness, shouldn't newidle_balance() prioritize fast task acquisition? A task-stealing mechanism can be effective in this regard. 2.Refactoring: Instead of a standalone fix, we could track LLC overload in sched_domain_shared and add a lightweight fast path atop newidle_balance(), gated by rq->avg_idle. Do you think refactoring along these lines to integrate into the existing framework makes sense? Thanks, Chen Jinghuang