From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from PH0PR06CU001.outbound.protection.outlook.com (mail-westus3azon11011030.outbound.protection.outlook.com [40.107.208.30]) (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 9B9C430BB83 for ; Mon, 12 Jan 2026 05:14:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.208.30 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768194859; cv=fail; b=ncy8T7hs9ZVmURFKIJNg4a4J+GKkbYm42gP3BPJPHs7AmjQDnar0scKmCcCYGVazEGRiWHE2Z3QOR4ajiNWckILIXD17N75P7lK9eqDfSL5mZCfGiWbL8H2rW9zIbzDzqQkyBj5617OFhwKWIjkp3/EHCnS7HcXe0WxrO/R785Y= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768194859; c=relaxed/simple; bh=vImG1PQEEGb5iwzlxWdGqVnCqgo/2+O2LyuQXsBm51U=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=KBquz7bcO3cTetLpIRDQxE7TBJxrVHf5vdUAuny1doygtAT28hoRMGJsD0BQ2CL5lUEEL5A3niGc4Ob2S4FaMcu0Rr2m3CEehqBHc2gOPZYPODVJindvoCJ+TWuVH/uT78/66/ozV5PjqVbIX9+ORqjhQEzjC3aIk/6I0y43DYA= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=IyFxNZ76; arc=fail smtp.client-ip=40.107.208.30 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="IyFxNZ76" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nE4UnyKE4Ww7xeTGNLcXIQI3DkAIoQHHELnB4MGMud3dIg94JmPLQCyg2o0Fp8bJNKd708yeQiG70oB48DemLvWlghhK/VUv4GmLHWg3+ysazd604SrRJe04hDwarf9BtjAMlR7M8pB5sxzRtOaF9W7ngxqFMFCywIABP8Hih7VeqMxPZjTMF8gLq34XO9DiCDzXWgQI2/icImdUuxCHdkYyb8M0d0Fn+ArJDc+cTN7OlZo/3PU+deaAyW1BVhqbHrwIYEeN3ZwT11Sb/7emfVjLRl0Zsbt9zuH0qWZABEVpCtqFtWoiRai8mNE++VnaEQR7tYrYTTAeMSluIwdW9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mDA73THx+PJcBmXXx/i2e4FUhUmJ5YBodR2MBExePiE=; b=p9IIGKxcwphysFcMxNeKIOjPlkWOTKpO1qKuOBmPhju8niOvvaamYCEwTi812I3Upz0BKdfL/Io4zyVqlLu3VjgDaLdYph05JxwZWcb3imFagMtsKIHY5WgLtZLPuhSiDnPtpi131DEK1MU/9wFp+25OiY9PLcbJTUravrZSrtqfukNm2qrvJ6g7BuJM4N7zA/XLOK7//ZiUifG9u7WgTsdEvfzQMmsm5qKYRfAFWTKW/RqI3FiIBpbswPVGEVNFNSNKgiBcxbp0nfIjhuhdDw3huBKbuypcMIKSKTWtlrLLGo0vXKb5/USBOBQjIA/MXs+rWCM7KY6GK2lZElOBSA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=atomlin.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mDA73THx+PJcBmXXx/i2e4FUhUmJ5YBodR2MBExePiE=; b=IyFxNZ76YaeR3IsphMojDS6TW9zlsdkb3nIsgilaHF+RR3FBH5pXcfmhE7rsI16S5bIru89/cX5IgBc+LsK0swQo/NkmtIHlcLrm9BPMaDJb5p87Sb8b7oDPYNUVa/xRbnqmKaXHwnXt4tHAfsF/xHQBjyXuUA68vOy6uW4KLAo= Received: from SJ0P220CA0001.NAMP220.PROD.OUTLOOK.COM (2603:10b6:a03:41b::7) by DM4PR12MB5916.namprd12.prod.outlook.com (2603:10b6:8:69::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9499.7; Mon, 12 Jan 2026 05:14:13 +0000 Received: from SJ5PEPF000001D5.namprd05.prod.outlook.com (2603:10b6:a03:41b:cafe::82) by SJ0P220CA0001.outlook.office365.com (2603:10b6:a03:41b::7) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9499.7 via Frontend Transport; Mon, 12 Jan 2026 05:13:44 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF000001D5.mail.protection.outlook.com (10.167.242.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9520.1 via Frontend Transport; Mon, 12 Jan 2026 05:14:12 +0000 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Sun, 11 Jan 2026 23:14:08 -0600 Received: from [10.136.46.14] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Sun, 11 Jan 2026 23:14:04 -0600 Message-ID: <4b3cabf1-76ff-4d1a-be1f-ab3fe3bfd935@amd.com> Date: Mon, 12 Jan 2026 10:44:03 +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: [PATCH 1/1] sched/deadline: Log Fair Server re-enablement for symmetry with debugfs To: Aaron Tomlin CC: , , , , , , , , , , , , , References: <20260109031959.2786873-1-atomlin@atomlin.com> <20260109031959.2786873-2-atomlin@atomlin.com> <0e76c836-c645-4fd0-9d86-b47b8834eac2@amd.com> Content-Language: en-US From: K Prateek Nayak In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D5:EE_|DM4PR12MB5916:EE_ X-MS-Office365-Filtering-Correlation-Id: 26a3870a-e73a-44b3-f053-08de51996ca0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|7416014|36860700013|1800799024|13003099007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?SUZpS1hoMlZRamdiWXp1MCtKaittdkRvaFlIZnNJQlpnYloyK1ZteFQ5OERp?= =?utf-8?B?WWdMcFJjTThOSkh3Tng5b040NkR6bFFvaVErVzUrM2d4KytpMkVGL3VZY0Uy?= =?utf-8?B?ZnYrS3R1MGRsUmZYUStGdFZ1SkxKYVl4dG5sTjdlZVc3eGJQRTk1RDRkUVRx?= =?utf-8?B?eERLVWltL1NhK20vMnhvQ1I0S1lRbTE3V2NiT0YvUUVZT0dQbjBNVW0waU9r?= =?utf-8?B?dGgrZ3VkYk5mWGZORm1ySXQ2U1hncWlISjUzSnpVaDQxWGdxa0xhV2FEOFQ2?= =?utf-8?B?eTVpUDgyQXNKUGZwbnBmak4wWGJUK0JPOFlvRGtPK1lMb1dtOW5nVkF6V1FN?= =?utf-8?B?T21MamNwVTF6OXpRcE1sckZ4RFJKcXE5dWQrYXRPMGRvSkwwcE1NZ1VLbWh2?= =?utf-8?B?czJ6WFF4VDl5RWp0NzhWYmZMYTR6a1JjQVlPdXJ5aGNLMUYvRWk1QUJtU0po?= =?utf-8?B?bG5YeDRtQzhBN1NhZlBNT0dGZWVHR2lyWWlVUzNTMVhYT2NQazZ0cEJrN1Yv?= =?utf-8?B?MGxGSU42d0M2WUR0NTdab1U4c252UGNzNVdNaTMvQnE1TmpSb1dHVFNMVldn?= =?utf-8?B?Y2tzaG9tWks3SStkV1lZRHVFaTFrcWF2RnU2K0pOYzhWNkpHaGY4THM2YndB?= =?utf-8?B?WjJqaWRuR3VGekNIV3A2QXZkY00rdHhpTUx6VklZVnAvb0Q4b1JEV2IvL3lt?= =?utf-8?B?eEY4NkxUMGx4Ni91azB2ZGN1YWl6MFZQdW05bGl1YjFQNUN4S1RPcFgzVlVz?= =?utf-8?B?VkliU0MwcEtpbmcxZlh6UE9rVzJiSHF5WXEyaGV1a0o2Nms4RnNVOHp2aVE3?= =?utf-8?B?TWpsNE1QMmJQaHBDcVBadnFYSEtpQ0VJZ3o5TUorOEkzcFJUSlpUNHZtMDdT?= =?utf-8?B?ZVllQnNYT1V2NVhCakR2U3IrczE1VHI1U0RmYi91dXlPU3hpbEZVa0FObS9h?= =?utf-8?B?ZVJVL2k2ZlVsekVYeFBOSUc1ck1Lc05pa29ucXI3ckhCaWM4c1RoejROL3Qv?= =?utf-8?B?R1FNUWFuc1ZDYmxPcjBqbmwvU29tYWNpT211enZwZzZOSG85VjdTYndKOVNM?= =?utf-8?B?bmZEczNmTUg3bTJ1VWx5MExJYW9mYVhnd082TWRVcmV1bU9RT0lmYTR4K3ZL?= =?utf-8?B?bnNDL3lqbGJrNGlGdEo0WW9ld2Y2Z1owVzhqQmNNK3ZaWGhMNVZabHo2VGdY?= =?utf-8?B?NGt6UWNMeEVDeHBCZlVLZldmYmdRc3p5QTJub3ZlNTJZNXZib1pYNVZBbWc2?= =?utf-8?B?eVJIVUkzeWQ4NTA1eDZlS3k4M2hNcWVrenNrYWFtSEpLZEtaQ043TlFPZFdX?= =?utf-8?B?eGZSVW0xNlEwd3lKVWRxSFZ6R3p1dlNXcWtjRGpWOHdPM3g5Kyt3a0dEYmwz?= =?utf-8?B?aEtuZlpZQ2VkaysxeUxuWnpzMnNaRFNBaHhDOCtLTkgyd0lkYmtSRWdUMDQz?= =?utf-8?B?QkhhUDZjckJpN2o1WjEwRUtiS1Ztd0J2THJ2amg3T0lVdHpjV3JGRTdzWmdG?= =?utf-8?B?d1ZDektIdVRPaUxoZ0FPUHN4YmdHOGNpeTI5ZlRmaWZJeDFyTlZ5TWlzZzRi?= =?utf-8?B?QU1Idm96R1BaMEZWM29lYk5JbXZHamEyR0JQWWpZRE5wTWR2NEo5UDN0K3Fn?= =?utf-8?B?a2lGcGorTThRVVd5Zk1EVEMxaHdSVDlWejRnUGQ5RXJKdFVhR3RaOVhCQ2h1?= =?utf-8?B?VmtGSzd1OWJTbXlhOVpxaDFiRDJoOC9GS1g3dGNqSWozNXRxbUFlYlpuMnFq?= =?utf-8?B?YzVteVFScG1Jd2l0Z3lxNVBpbzRjaXg2WThPeEVJZ3BXS2J6SGJNYzUzc3ZS?= =?utf-8?B?dm92L3NKMWxvdVBrTGQ4UkRUdi9SMFlac1RrdkhxTzJOaXZ0V01zVlRxUm1V?= =?utf-8?B?cVlLS2Y4RFlpYnF5dFJkNTJWOEowOGVzNW02Ty9WSmo3Rmp5OVVTWEZTaWhn?= =?utf-8?B?SE5EcEt1WXlpZDdndXhwVGJhSU9BQVpjOWh5SVdlU0JlKzMvSm1Yc2tpUFU5?= =?utf-8?B?WldtcHBNcXl5MHErU0ZrY3dxcXkyS3FPcFRpVEgzR0pkUlhaMzZoU1BvYkFn?= =?utf-8?B?ckVCYlk3WEpwYmFORHpOU3ptcXBocW1ZQlNOZTNOcEZlUU5iQjZyd1JuMjNr?= =?utf-8?Q?RpFc=3D?= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb07.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(7416014)(36860700013)(1800799024)(13003099007);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2026 05:14:12.6694 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 26a3870a-e73a-44b3-f053-08de51996ca0 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001D5.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5916 Hello Aaron, On 1/9/2026 8:00 PM, Aaron Tomlin wrote: > Consider a strictly partitioned environment utilising isolcpus=domain,5-8 > alongside nohz_full=5-8. A latency-critical SCHED_FIFO task executing on > CPU 5 that never enters the kernel requires absolute isolation. If a > SCHED_NORMAL (CFS) task is enqueued - perhaps a CPU-specific kthread or > some other user-specific task - the current architecture wakes the Deadline > Server, which in turn restarts the clock-tick - see sched_can_stop_tick(). > By temporarily disabling the Fair Server via the debug interface, an > administrator can preclude this interruption during a specific, sensitive > window of execution, before restoring standard operation once the critical > phase has concluded. I believe the suggested solution to that was to trace the reason for the kthread/fair task waking up on isolated CPUs and prevent the wakeup if it is for some unnecessary operation as opposed to disabling the fair server. We have tools like https://docs.kernel.org/trace/osnoise-tracer.html to capture these noise. Trace the noise, bring up the case where isolation is broken on the current *upstream* kernel to the mailing list, and we can solve it for everyone instead of disabling fair server as a duct tape. [..snip..] >> I still think once the fair server is disabled, the pieces are for the >> user to keep. I wouldn't want us debugging: >> >> Fair server disabled in CPU X ... >> Fair server re-enabled in CPU X ... >> INFO: rcu_tasks detected stalls ... >> >> only to realise the stalls were a result of starving the fair threads >> and the fair server didn't run in time / didn't have enough B/W to >> prevent that stall. [..snip..] > Regarding your concern about debugging RCU stalls and the "keep the pieces" > philosophy: I would argue that this is precisely why the symmetry in > logging is essential. I would argue that fiddling with the fair server is a terrible idea and once the user disables it, all bets are off. It becomes their headache to solve. > > Without the "re-enabled" marker, the audit trail is incomplete. If a system > stalls, seeing only a "Fair server disabled" message leaves the duration of > the starvation event ambiguous. By explicitly logging the re-enablement, we > establish a definitive timeline. If an RCU stall occurs shortly after the > server is re-enabled, the timestamp provides the necessary evidence to > correlate the crash directly with the preceding starvation > period — confirming that the user's intervention was indeed the root cause. > Transparency, in this case, expedites the diagnosis of "user-induced" > failure. Juri, Peter, is changing the fair server's bandwidth frequently very common scenario is the field? If not, can we add a pr_warn() for when the fair server's parameters are changed by the userspace just to catch any absurd values that reduce the bandwidth to a minimum without disabling the server? I can do something absolutely stupid like this without dmesg logging anything that would indicate I'm being stupid: # echo 4000000000 > /sys/kernel/debug/sched/fair_server/cpu0/period # echo 1 > /sys/kernel/debug/sched/fair_server/cpu0/runtime # sudo taskset -c 0 chrt -r 99 ~/scripts/loop& # taskset -c 0 bash -c 'mkdir /sys/fs/cgroup/cg0; echo $$ > /sys/fs/cgroup/cg0/cgroup.procs;' ... wait for a while INFO: task bash:4272 blocked for more than 120 seconds. Not tainted 6.19.0-rc1-tip+ #162 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:bash state:D stack:0 pid:4272 tgid:4272 ppid:4271 task_flags:0x400100 flags:0x00080000 A taint might be too far but a log should be acceptable? -- Thanks and Regards, Prateek