From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 2727938E8B3 for ; Tue, 12 May 2026 12:28:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778588891; cv=none; b=HHAWRAs3szTl5NvxxmchP3Eo44ecGba7/ims4Eom6TVwSgJB2z+E0FPzvKVLL4AsWjJBoCSKHfBOAmSlOcEhjfthiRNhwCFW66Mc4VDFSwxKWsBWRi1XteoZdEPzsTCu53eMVViaC/zAE0gKkuarmZfcFYGjp7GYipCzM6k9NgM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778588891; c=relaxed/simple; bh=BNQeXE6pA2sgy1e53EflmSeral1O1Uupgklq4K7Tye4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dJRsYNZwxMgUNHefgLwP3Lheu7fepVq9jii8QuUj1Fofae1HNAoOSKzGGmYGyOoN1cf/jExJlGtFCjp8m5vukRXHVhuzlDuEfuPTSThyWglwlvmxo5JRM2zCTOLfKFyy26RgvNey9ehcK6KJoSyYv7ZXPb85/tVwhJAiOUaaw7I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=P/2335rW; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=ZN9FHhYZ; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="P/2335rW"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZN9FHhYZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778588884; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iycANBc9rw+3F8pZdRf7BPXjL9R4GxVaKqIpfjCmDHs=; b=P/2335rWNNK1sVC/Z9j9AgDYgi/s9UCqR3fBykfhNRu/QEy4u/IXXtngkPa7Tv9gVeuFJu whPwh1HoFfG9KeLmNWxKhz0ALfUVVXGDzsG/tQTPr6b415I8pyIM9A2qHCGfRi3a5GpzQR 3qAMK63qGdU/fbOzdG3yO9iFo0s4O40= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-345-Epqx9Iw8NCmbJgOZwXFqBQ-1; Tue, 12 May 2026 08:28:02 -0400 X-MC-Unique: Epqx9Iw8NCmbJgOZwXFqBQ-1 X-Mimecast-MFC-AGG-ID: Epqx9Iw8NCmbJgOZwXFqBQ_1778588881 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-48d127eb013so30929785e9.1 for ; Tue, 12 May 2026 05:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1778588881; x=1779193681; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=iycANBc9rw+3F8pZdRf7BPXjL9R4GxVaKqIpfjCmDHs=; b=ZN9FHhYZiscV0QWIPLGG3RSLZp+/gKarinpNrJASzLFvwU2nHSGqDH2bo8rD+H4Ikh BW8h3epLhn5QnkQRXrW5UK2XG1XHV76RaHOafueyORoi08HWzIq01zqINVDFFkmW7vm/ FFr8rAUa+H8E1hwn0v21LMs4TIH+JVQhwxfQSB9qSOWWKVpqIotgX4INj0DqBTjTlujX XwYGNuS2iTxxFsXR6kS35EBr3pRP/eUV4iv5tLgvSio+SdHXaeVGVo7F+mfZx7YN/6Kw 7af+Me6DdSbVctA5XN+Ol1IK/YSkV6G44P13+VkFwtvpMbjcJNgbUGhU2Wis9m22NVc0 /5gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778588881; x=1779193681; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=iycANBc9rw+3F8pZdRf7BPXjL9R4GxVaKqIpfjCmDHs=; b=KzZe7iL8BZJGfIATvUjSt56F1k3V5BMLYLwoKNXhV91LKLdfBtpW8Dqq/pKYBcNK7G w/po/prRvPqwmXT/ASU+ES8Q7eQmoOHr0DVNogOohCASlI2srxOSDedfNV7S/U1/i3kv iD+72SAoC+9Xn+FuBlD35WCcOULYKbxVyEe1aD1j9S4uXETcKDqqcG0pl/TdxRtpnfwH 5qCIw2hy3EH5POlX0xAkTTfBsFdEr9wNuGTCVNcp170pSZEuZWwJF36qxVOa08RPWmYG agX3uJJpQQ52DSq4dzcHjNRohU5yILVY/6fNM1CWqX9t5zPegMJ37uS3QygPJiyd7sx6 SEHQ== X-Forwarded-Encrypted: i=1; AFNElJ+rTv/lfOKiTRAPPBnZenYzAxK3b2sa+MvNcvgmfZDEzePKKxkUFaQLmIyTt5Vf3qyYT1qsj2A/BTW8fUU=@vger.kernel.org X-Gm-Message-State: AOJu0YwQw+PhDbEDxlBrli6zXfDKNgejgbrefC1n/OrQ9W1BKJnt3ZKx xH+eL7aCHMdBU1k64HdCM8iAON9pzOk5Nhx4Z3s12pjl6MRM2lDsiz/iOoCKjsfngCSRlHvOIfF sqFwr3v4PXgZ59NAqVnZkG/RL+LxnYg22WM+CNjn6pYZbzc0n+kDwzCi4xDKgiwwbJQ== X-Gm-Gg: Acq92OF0gWoAIT7fen8pYpN0LLIF80DO7kYyVrqHhWZDnlyv2Fs29w0gvqnaikuQp00 mYk0Y6NHKikjNq3Q9d53Eqm/Q4vM0ZU0H4HLK06U0xgELEfAH+r9ygZ3QGPFJq89sgDA/We8RGo tmnf2A2tRToguHH8JXunoiEeFDBGwXHerDj8yRTO9wYTM/El7WIYD/ZeoyJFczhjoCYwYiV2dee zK87WF1P8fkuZFqCf80PSYsQzuuT3T8iz0RrCH/4p9b15ClSGSzdT3W6B/DTUKL50f7ZrL6jQGm /UlCaqzjmRI8n2YH6CmkYsTVvAI7FL0lR99viKtu5Kr7WkFmRLpYD6ITxwF23N2hEWEqxDT2y4e kL90EVwUOe6iNaWTNpRjrfI113zIboOBn0eXVq3tOOfTNqMG5hXzm X-Received: by 2002:a05:600c:1e0f:b0:48e:51f5:2764 with SMTP id 5b1f17b1804b1-48e676c0353mr306210295e9.27.1778588881396; Tue, 12 May 2026 05:28:01 -0700 (PDT) X-Received: by 2002:a05:600c:1e0f:b0:48e:51f5:2764 with SMTP id 5b1f17b1804b1-48e676c0353mr306209685e9.27.1778588880989; Tue, 12 May 2026 05:28:00 -0700 (PDT) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.56.132]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e8e5fd648sm18029675e9.4.2026.05.12.05.27.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2026 05:27:59 -0700 (PDT) Date: Tue, 12 May 2026 14:27:57 +0200 From: Juri Lelli To: Furkan =?utf-8?B?w4dhbMSxxZ9rYW4=?= Cc: Ingo Molnar , Peter Zijlstra , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Andrea Righi , Frederic Weisbecker , linux-kernel@vger.kernel.org, David Haufe , Cao Ruichuang Subject: Re: [PATCH] sched/deadline: Make dl-server nohz full aware Message-ID: References: <20260512-upstream-fix-dlserver-nohzfull-b4-v1-1-a94844387ae7@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi Furkan, On 12/05/26 13:06, Furkan Çalışkan wrote: > Hi Juri, > > On 5/12/26 12:02, Juri Lelli wrote: > > The dl_server_timer() causes spurious IPIs on nohz_full cores, breaking > > isolation guarantees. The timer executes on a housekeeping core and > > eventually calls tick_nohz_dep_set_cpu(), sending IPIs to isolated cores > > even when only a single task is running. > > > > The problem is that dl-servers are not coordinated with nohz_full tick > > state. Timers can fire and send IPIs to otherwise undisturbed cores. > > > > Fix by managing servers in sched_can_stop_tick(): > > > > - When RT tasks run with CFS/SCX tasks, start the appropriate server > > and keep the tick running > > - When only RT tasks remain, stop all servers and allow tick to stop > > (except for >1 RR tasks which need the tick for round-robin) > > - When only CFS/SCX tasks remain, stop all servers before stopping tick > > > > Introduce dl_servers_stop_all() to reduce duplication and abstract > > server management from core.c. Unify RT handling into one block that > > handles both RR and FIFO cases. > > > > Fixes: 557a6bfc662c ("sched/fair: Add trivial fair server") > > Reported-by: David Haufe > > Closes: https://lore.kernel.org/lkml/CAKJHwtOw_G67edzuHVtL1xC5Vyt6StcZzihtDd0yaKudW=rwVw@mail.gmail.com > > Signed-off-by: Juri Lelli > > --- > > I had to modify my first original attempt at fixing this (please take a > > look at the linked report/discussion) to also take SCX into > > consideration. > > > > FYI, I temporarily pushed the script I'm using to repro and verify the > > fix here > > > > https://github.com/jlelli/sched-deadline-tests/blob/master/test-dlserver-nohz.sh > > --- > > kernel/sched/core.c | 43 +++++++++++++++++++++++-------------------- > > kernel/sched/deadline.c | 14 ++++++++++++++ > > kernel/sched/sched.h | 1 + > > 3 files changed, 38 insertions(+), 20 deletions(-) > > > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > index b905805bbcbe4..98759255c306b 100644 > > --- a/kernel/sched/core.c > > +++ b/kernel/sched/core.c > > @@ -1414,30 +1414,35 @@ static inline bool __need_bw_check(struct rq *rq, struct task_struct *p) > > > > bool sched_can_stop_tick(struct rq *rq) > > { > > - int fifo_nr_running; > > - > > /* Deadline tasks, even if single, need the tick */ > > if (rq->dl.dl_nr_running) > > return false; > > > > /* > > - * If there are more than one RR tasks, we need the tick to affect the > > - * actual RR behaviour. > > + * If there are RT tasks, we may need the tick (for >1 RR tasks), > > + * but we must also service lower-priority CFS/SCX tasks via dl-servers. > > */ > > - if (rq->rt.rr_nr_running) { > > - if (rq->rt.rr_nr_running == 1) > > - return true; > > - else > > + if (rq->rt.rt_nr_running) { > > + if (rq->cfs.h_nr_queued) { > > + dl_server_start(&rq->fair_server); > > + return false; > > + } > > +#ifdef CONFIG_SCHED_CLASS_EXT > > + if (rq->scx.nr_running) { > > + dl_server_start(&rq->ext_server); > > + return false; > > + } > > +#endif > > In the above block, the CFS and SCX server start paths are mutually exclusive. > If both cfs.h_nr_queued and scx.nr_running are non-zero at the same time, only > fair_server gets started and ext_server remains stopped. Could that leave SCX > tasks without server coverage in a mixed CFS+SCX+RT scenario? Indeed there is the partial switch mode to consider. Can fix in the next version. Thanks, Juri