From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (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 D184C30E84B for ; Mon, 20 Apr 2026 04:01:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776657716; cv=none; b=a4Ch+7XwZ/bN2yJbX58tJ7OSKC9715UrZCA9LUE8rofvGdKZjmYeLu+DkSixqcGLskK93CxJ4xhqSvJnFa0QbqbPbWP0PphGY7rJefz2AAmvpAk63KZkHGKguFxbmibviBnUMIWj8YpzIU/szDHK4AOOYpN6jX+bRXCY0gM5+Lo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776657716; c=relaxed/simple; bh=mLHfJGWpu+HVVQHZMSWehr2wtkaw2y/AyQVjsiaLIgQ=; h=Message-ID:Date:MIME-Version:Subject:From:To:CC:References: In-Reply-To:Content-Type; b=rnTDeRF/8Krel17KbiG192mi19deyYL/PGisLdsVlzJa1Pw74a3ECM5kuP9hG1GG/yYrTgxklNHhR31YW/lCWmdDcerkXNHBzAz52pruE5/MuSCfDCSxsJ7Anck8IEM+Yeh7DRlXBt+BN+zb/eamUyLTGA7sa5P1QNIizIyJ3J0= 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=49ANpOVH; arc=none smtp.client-ip=113.46.200.218 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="49ANpOVH" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=Byg4lNtUwjZe+q7EKgubavGgObRjTlgCY057ea0l4J4=; b=49ANpOVHFSH6ZqzgQnfL8mRagqDnpiTD7q+HbGuclw57yQZyQnzWNKcDbdbM30lO7uQBAD1Ru eMJHJ/qjitVWgfqU58MpTT026QGVX57T7nICcY/DfUywqLBDfXDUn+zSAx0JlK2HwArZh+hQdle eYCBzf8iqIzgEV9jRS91S9Q= Received: from mail.maildlp.com (unknown [172.19.163.0]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4fzWq01V7HzpStt; Mon, 20 Apr 2026 11:55:24 +0800 (CST) Received: from kwepemr500016.china.huawei.com (unknown [7.202.195.68]) by mail.maildlp.com (Postfix) with ESMTPS id 0297240537; Mon, 20 Apr 2026 12:01:45 +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; Mon, 20 Apr 2026 12:01:44 +0800 Message-ID: Date: Mon, 20 Apr 2026 12:01:43 +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 From: chenjinghuang 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> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemr500016.china.huawei.com (7.202.195.68) On 3/28/2026 10:48 AM, chenjinghuang wrote: > 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 > Hi, Gentle ping on this RFC. I'd appreciate any feedback whenever you get time, or let me know if I should resend/rework anything. Regards, Chen Jinghuang