From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 80D983093A0 for ; Tue, 6 Jan 2026 09:08:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767690505; cv=none; b=Oa76GEuWKqzskKUoZdqAgrih1S/q0JJ/+8OjXVbhDZIamVjvL2oO6sNIxAENj3y30fgDjpdEmrAS4CKPD2zRj2BWHVvtDuZjaN2BFo056RAwfIDopV4l6LifJ7e60t3oUBKw4apgAWJWJO51QYaLF/WoGYSYbaxed6EJaJtIz0A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767690505; c=relaxed/simple; bh=zlfZKtQ9viIxqEREqJfDr6HdFYOeErnGEzMEzpsYNRA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gTyUsodygpk0752UsYnlGXsuUQXRqSuK4xrSd5xAgpvRI8SH/vKjquzquOP/A9fxDFYZL+oIWplUotJdFgL1kQYnAeytvt7ai/4DsmDu9jKyXoixgTUYh7biviotKJs64cw0VXkMt+97QSJkuWSOEtxyqrFypFkLRloOE/iZpWQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=DE4KDVnO; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="DE4KDVnO" Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 6065uZ8e023995; Tue, 6 Jan 2026 09:07:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=ecu3nz 23/MsWUisFo7BY7CevJzjG5ZiV6kQqLlYFlW0=; b=DE4KDVnO+7WyNzVQBBSJ6w EQG+zAhomkJ7LMC2Kp4Cashou845Ga1IPQPnTTI+gniyuXnInE4Zf33K8k0dLENa CIjwLFtBkzO2BwbIYHD8ZZdWWsfVonQ2DMsy1WimPreUEuSUUAv7ntWWCtczKD/9 FKrI79AKwIx6FyqSMvUAWaQHPxdELRtaxl774EBAvS4kuTI0JXsA0DXjTLfyMNQT WPMa0FBG/CcmSWaalIDEombAEoA19xvif9lyBsQyKzSvDyZPh+0+FsCSDe/dh8cr JqyZW+tXEdG6SdygBxch6QO3fUNclEx8hXIycqyo92WctW7HJn1cGIWgO4gARm0A == Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4betm735yu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Jan 2026 09:07:56 +0000 (GMT) Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1]) by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 6068meXR020553; Tue, 6 Jan 2026 09:07:55 GMT Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4betm735yr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Jan 2026 09:07:55 +0000 (GMT) Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 6068e7AK015205; Tue, 6 Jan 2026 09:07:54 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 4bfdesam1g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Jan 2026 09:07:54 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 60697rTx55247140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 6 Jan 2026 09:07:53 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 198A720040; Tue, 6 Jan 2026 09:07:53 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1509420043; Tue, 6 Jan 2026 09:07:50 +0000 (GMT) Received: from [9.39.31.190] (unknown [9.39.31.190]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTP; Tue, 6 Jan 2026 09:07:49 +0000 (GMT) Message-ID: Date: Tue, 6 Jan 2026 14:37:49 +0530 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 0/1] sched/fair: Feature to suppress Fair Server for NOHZ_FULL isolation To: Aaron Tomlin Cc: neelx@suse.com, sean@ashe.io, mproche@gmail.com, linux-kernel@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com References: <20260106034209.2703289-1-atomlin@atomlin.com> Content-Language: en-US From: Shrikanth Hegde In-Reply-To: <20260106034209.2703289-1-atomlin@atomlin.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Authority-Analysis: v=2.4 cv=OdmVzxTY c=1 sm=1 tr=0 ts=695cd0ec cx=c_pps a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17 a=IkcTkHD0fZMA:10 a=vUbySO9Y5rIA:10 a=VkNPw1HP01LnGYTKEx00:22 a=ZjhdDiGTb9-IOKU7xvYA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-GUID: DghJWdb4LE19A7-LO-rDvUxloFUfpJV5 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTA2MDA3NCBTYWx0ZWRfX+53JDb+2eK9S KELpj+bm2hTzedgLOflqQ2PempzmmhUIIfV+AhTcS3KcOjJKgAX+QOxpLEJJcgVHEP9hP5PqPde 5bWDh7t04BJQVkLMub4VOzlU3ThKmjyZLSWg8ospMqZMCI1aRyXQxHN8W9hIowY6pt1QLSFshyT eyApwLe/ddYSvMpZNO7JX0QzMUidBmvQT5soF5RHAUvYv67BJl12hgbvz5S8Q9icqYyWzyuK6SY CdZ4cB6tj0eZF5tG2BWnxVWfnk/vmMOIxNSpOQ5tushwbZy9l2eVPoFhyvFdIam3GxNw0mRtYR6 CRa4D/0+yOMgeEInJdUAvLq7PAJVJk382yM8NnJiVW8tyN80thWqQQRFtb0BW2FwNz2CKaJ4Xvq QX8OpIs4GmWO/j8Xl/P7PVVQhMErEeVl4EtPNhrb9WUCmzUIqDiL1jqUSuaBZX/sowXddDBduw8 DTHRH2ZPXyPp6cq3W7g== X-Proofpoint-ORIG-GUID: a3MiOdWqQ0JnYJ7Pg7gVt6AAjGQIC309 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2026-01-05_02,2026-01-05_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1011 phishscore=0 malwarescore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2512120000 definitions=main-2601060074 On 1/6/26 9:12 AM, Aaron Tomlin wrote: > Hi Ingo, Peter, Juri, Vincent, > > This patch introduces a new scheduler feature, RT_SUPPRESS_FAIR_SERVER, > designed to ensure strict NOHZ_FULL isolation for SCHED_FIFO workloads, > particularly in the presence of resident CFS tasks. > > In strictly partitioned, latency-critical environments (such as High > Frequency Trading platforms) administrators frequently employ fully > adaptive-tick CPUs to execute pinned SCHED_FIFO workloads. The fundamental > requirement is "zero OS noise"; specifically, the scheduler clock-tick must > remain suppressed ("offloaded"), given that standard SCHED_FIFO semantics > dictate no forced preemption between tasks of identical priority. If all your SCHED_FIFO is pinned and their scheduling decisions are managed in userspace, using isolcpus would offer you better isolations compared to nohz_full. > > However, the extant "Fair Server" (Deadline Server) architecture > compromises this isolation guarantee. At present, should a background > SCHED_OTHER task be enqueued, the scheduler initiates the Fair Server > (dl_server_start). As the Fair Server functions as a SCHED_DEADLINE entity, > its activation increments rq->dl.dl_nr_running. > There is runtime allocated to fair server. If you make them 0 on CPUs of interest, wouldn't that work? /sys/kernel/debug/sched/fair_server//runtime > This condition compels sched_can_stop_tick() to return false, thereby > restarting the periodic tick to enforce the server's runtime. > To address this, the patch introduces a new scheduler feature control, > RT_SUPPRESS_FAIR_SERVER. > > When engaged, this modification amends enqueue_task_fair() to forego the > invocation of dl_server_start() if, and only if, the following conditions > are met: > > 1. A Real-Time task (SCHED_FIFO/SCHED_RR) is currently in execution > 2. RT bandwidth enforcement (rt_bandwidth_enabled()) is inactive > > By precluding the server's initiation, rq->dl.dl_nr_running is maintained > at zero. This permits the tick logic to defer to the standard SCHED_FIFO > protocol, thereby ensuring the tick remains suppressed. > > Considerations: This serves as a precision instrument for specialised > contexts. It explicitly prioritises determinism over fairness. Whilst > enabled, queued CFS tasks shall endure total starvation until such time as > the RT task voluntarily yields. I believe this is acceptable for > partitioned architectures where housekeeping duties are allocated to > alternative cores; however, I have guarded this capability within > CONFIG_NO_HZ_FULL and a default-disabled feature flag to obviate the risk > of inadvertent starvation on general-purpose systems. > > I welcome your thoughts on this approach. > > > Aaron Tomlin (1): > sched/fair: Introduce RT_SUPPRESS_FAIR_SERVER to optimise NOHZ_FULL > isolation > > kernel/sched/fair.c | 19 ++++++++++++++++++- > kernel/sched/features.h | 9 +++++++++ > 2 files changed, 27 insertions(+), 1 deletion(-) >