From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from va-1-112.ptr.blmpb.com (va-1-112.ptr.blmpb.com [209.127.230.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D9F3C201004 for ; Mon, 1 Jun 2026 06:19:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.230.112 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780294744; cv=none; b=SUEx8+DkST3+s7fbuxvFMDG6WsB+sY0fqIzK+gmKFHdql65thWhpSZWKrI5VRIP1AIOrORfy9i0ggo81jOBwPQfVEi68N6ywPEShQSSILB36kv3RLJfK10Rn0naKMOh0rkachE4JegswWRnlLdDTJC7sKrEnp96dho9Hfhllsao= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780294744; c=relaxed/simple; bh=0xzMd9x10Y9NHJNMCL4BPWteAxnmhn1Xrb6fiKdOx3g=; h=Cc:Message-Id:In-Reply-To:From:Content-Type:Content-Disposition: To:Date:Mime-Version:References:Subject; b=DPAb3H1BNRPiPs7FZr9mHvsYjagp0L/7Fg3hUHC50j2qBlBFl+cvXrkwzbsGJTXmqkvdd8Vy/fIIrapWtbk5IBWTQ4Q9GbL8K8aZWjPhX0yMezB9OjywlA/ZqcwGnjzCdgm60W+a2fOy1LaeRFOLXJGBwWDcsLzXJhLMdC+V9Ac= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=WMgLKZMe; arc=none smtp.client-ip=209.127.230.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="WMgLKZMe" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1780294731; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=fkTo3UZmYVkbSU5Vx3g98b8bUTFtF0dyYpc6SGY4+h8=; b=WMgLKZMeOjEGo4cEN+q7a0BVG9JH6WPSavlFJID38NdkcC/MV+LLDRmaRtK8xMBAXkHWkh 3Vtha9qYmtzeaTqKhI/Cw07hzAIag/JevXsTAOTpwBUtEcQTfYjpNPFEr24HLnIlKEQhXE mVyoa9L+MaJjv4P7Rff9pF11+EWDvEi/MQvdq4W2TPFEYJNmEbzBjm0GTcJvCGyKlVMxnj qN2Mp+26eYFGQb0b3AG/xPZNxnY/EK2sm+QMEpZb6B7ojj32oWhxP6mqZkYMNhwN3FButd jr9oTJO9Ivsy8Yx8J0iQPlXbzGGWGW8JRVMa2Kw23bLPSniLXSBEG0aBCTVSjg== Cc: "Ingo Molnar" , "Peter Zijlstra" , "Juri Lelli" , "Vincent Guittot" , "Dietmar Eggemann" , "Steven Rostedt" , "Ben Segall" , "Mel Gorman" , "Valentin Schneider" , "Josh Don" , Message-Id: <20260601061832.GB690044@bytedance.com> In-Reply-To: <20260528094830.13291-1-kprateek.nayak@amd.com> From: "Aaron Lu" X-Lms-Return-Path: Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline To: "K Prateek Nayak" Date: Mon, 1 Jun 2026 14:18:32 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260528094830.13291-1-kprateek.nayak@amd.com> Subject: Re: [PATCH 0/5] sched/fair: Allow account_cfs_rq_runtime() to throttle current hierarchy X-Original-From: Aaron Lu Content-Transfer-Encoding: quoted-printable Hi Prateek, On Thu, May 28, 2026 at 09:48:25AM +0000, K Prateek Nayak wrote: > The current hierarchy is always throttled in __schedule() during the > pick when update_curr() detects a cfs_rq running out of the bandwidth > and issues a resched. >=20 > This was necessary prior to per-task throttling where the entire > throttled hierarchy was dequeued at the point of first throttle during > the pick but with per-task throttling, tasks continue to run as usual > until they exit to userspace and dequeue themselves one-by-one until the > hierarchy is deemed fully throttled and the PELT is frozen. >=20 > throttle_cfs_rq() is now simply a propagator of throttle indicators and > nothing more. >=20 > Unify the throttling for current hierarchy under > account_cfs_rq_runtime() which is responsible for the time accounting. > If the bandwidth runs out, account_cfs_rq_runtime() will request for > sched_cfs_bandwidth_slice() and mark the hierarchy as throttled if it > fails to grab bandwidth. >=20 > throttle_cfs_rq() will do a task_throttle_setup_work() if it finds the > current task to be on a throttled hierarchy and the task will naturally > dequeue itself when it exits to the userspace without needing an > explicit resched. >=20 > First four patches are cleanups and preparation for the final bit that > switches over to using account_cfs_rq_runtime() for throttling which was > provided by Peter in [1]. >=20 > Following are the results of running hackbench running 3 levels deep > with the setup from "Testing" section on [2] when compared to > tip:sched/core: >=20 > kernel : tip tip + series >=20 > Min : 207.33 202.20 > Max : 210.20 222.47 > Median : 207.83 218.33 > AMean : 208.29 215.36 > GMean : 208.29 215.25 > HMean : 208.29 215.13 > AMean Stddev : 1.02 7.37 > AMean CoefVar : 0.49 pct 3.42 pct >=20 > All numbers are in seconds. >=20 > There is a slight boot to boot variation for this benchmark but the > utilization numbers in top is more or less similar between the two. > Additional testing and feedback is always appreciated as usual :-) I tested hackbench and netperf with quota set on a 2 sockets Intel EMR and the result is in noise range. Hackbench(in seconds, less is better) base: 176.114420=C2=B12 head: 176.214394=C2=B13 Netperf(throughput, higher is better) base: 14071, min/max: 13376/15261 head: 14769, min/max: 14095/15588 Feel free to add my tested-by tag after the clock warning is fixed in patch 3.