From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 03EF13F7A86 for ; Wed, 13 May 2026 12:09:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778674153; cv=none; b=HSqriPCHOYnPTAh0U2YkKjREJ20sPVI/Rqy6HbLS3mrKb8bUaxVNCbBBZY2MdFjjiye2IolaRn3peBVIKLn9+hp0FfgKEktwOawlTkbwgMxW4Olzn7wtFECzMQA+Wxn54GnrwBGy8kqUC8citrS3b8ZSTGzwYUr3cH5lLiFBC0o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778674153; c=relaxed/simple; bh=tm1JiDDlYXR6kdqow3eOnt7bKbD9VJafIUodCyEnq1o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tV/H7tNblNieDtDGrbkS1mZa5rZ+kRn/RuEjH3p07IlIg5mWgE9rMRU2T1B+ssSdiIPx5qpy0HBOJjAn5vAK9c9o+yz6X+aMtYpZ80hykLFhJUzWQVkWLOSUHfo65fzbjqSCI5FjNqwx52TDO6yfCJE8kopnZU/cmtuOxmOFCTA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dtOKT+Nq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dtOKT+Nq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C29FC2BCB7; Wed, 13 May 2026 12:09:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778674152; bh=tm1JiDDlYXR6kdqow3eOnt7bKbD9VJafIUodCyEnq1o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dtOKT+NqU7CQyFH4DusDgOeYhnlYOVC5g8L2QA8fgAt6VNlQa90VPPE762SJfXL+q q56ebm29t0ilPhcjLwr7UEKcac1rj1I9Y6QICM0wAj6mY7BiSDrYOSimDra5hsCrdV 7e185clN9kBtVxQqHibORHk9KqKoNnr/Ri7ikhsmOOV/+ddQS37OT8P/8Dgmbclxkb 1SQZDPCYeTOd7h+1m6dIV7DzOujMGmPqv/f4EgGXtxnawVchmlSvWnz7Ht40feJ+bM /aFk5RSSUWjEhm4jR3RQ7kH726eOeQi6wpmWiwoxpP77JS7tncLFiCnWj8oZXX/huC SlefqVMfPP3Cw== Date: Wed, 13 May 2026 14:09:09 +0200 From: Frederic Weisbecker To: Andrea Righi Cc: Juri Lelli , Ingo Molnar , Peter Zijlstra , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Le Wed, May 13, 2026 at 08:38:46AM +0200, Andrea Righi a écrit : > Hi Juri, > > On Wed, May 13, 2026 at 08:16:21AM +0200, Juri Lelli wrote: > > On 12/05/26 17:34, Juri Lelli wrote: > > > Hi Andrea, > > > > > > On 12/05/26 16:55, Andrea Righi wrote: > > > > Hi Juri, > > > > > > Thanks from the quick review! > > > > > > > On Tue, May 12, 2026 at 11:02:37AM +0200, 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. > > > > > > > > As mentioned by Frederic, we don't allow to load BPF schedulers when isolcpus= > > > > is used, so I think we can simplify the sched_can_stop_tick() part. > > > > > > Right! Thanks for confirming. > > > > Ah, but wait. IIUC SCX is incopatible with isolcpus=domain only? > > scx_can_stop_tick() seems to confirm we need to take care of it when > > domain flag is not present. > > > > So, maybe we still need to consider SCX in this patch? e.g. in > > configurations that are not using static domain isolation, but isolate > > CPUs by configuring tasks affinities. > > Ah! That's right. SCX is incompatible with isolcpus=domain, but we do support > nohz_full=..., so I think your original approach is correct. It might be worth > calling out explicitly in the patch description that the SCX handling targets > nohz_full, so we don't make the same mistake in the future. Most of the time (I'm actually tempted to say all the time), nohz_full= doesn't make sense without isolcpus=domain, or the cpuset equivalents. Because nohz_full is always about workloads that can't bear a few microseconds tick latency, so why would these workloads want load balancing, kthreads, etc... ? And in fact why would such a workload want a scheduler at all? Thanks. -- Frederic Weisbecker SUSE Labs