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 3C8893AA1A8 for ; Wed, 13 May 2026 06:16:29 +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=1778652991; cv=none; b=iraWw9Km/ASm+dDSttslvjRfOxWtQVOot5uKyy83NmX1P1PYhveGOKyJDczjTO+eQC9p8l24b9hIDmBjz30NyvUEilGhiv8fTxA4KJVk4QLASJfSjaZBD2qdi1GErpsqj+w+wqOkpW+3kyYo0CxP9kVDWR0VdYHDVnjSifU7GVQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778652991; c=relaxed/simple; bh=nbqAhYPRf+8Sk8fEzCzrXiKAjCJfnl5FHOeSFFmjpQA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LEy8+MPOh6jwBj62NyXT2C1dsrhs783L4FxNAvduCDF4j/5RBmokX3rvEFV0fLwcp0OawCmjOU11It73aa6AgF2SytJzf75FiLMgw4ZqK8oEkfjtpzfsGiAjYIVFx9AyJYgiRV87onG33P1SVD7bF40cz12NEZ5R4gECdhN2zMg= 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=Fas9oe2H; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Z2rwCXRq; 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="Fas9oe2H"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Z2rwCXRq" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778652988; 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: in-reply-to:in-reply-to:references:references; bh=l3Ulf58yT3vhnufJD/rFrfr3G1F78g9P4XwZKEEuLJE=; b=Fas9oe2Hk//sTAxyJP5fhmZ7mFWCRLmEs54gLnsZl8yUcd4mIAXbi6obO4I4ieixffmRfW WTTY5FqSiYS4+VU6/ZU/DvxHFLGWJFnVfk43lhvrNoJ1RMpAs5pXsI79Z7mQ3+OBGI8+Q9 Fh5qt/2TSZkvvcw+YirzXkr4iAM1x5Q= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-611-KL1RhheLOUakCZkn4QyWTg-1; Wed, 13 May 2026 02:16:26 -0400 X-MC-Unique: KL1RhheLOUakCZkn4QyWTg-1 X-Mimecast-MFC-AGG-ID: KL1RhheLOUakCZkn4QyWTg_1778652985 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-43d7b7bacddso4121293f8f.0 for ; Tue, 12 May 2026 23:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1778652984; x=1779257784; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=l3Ulf58yT3vhnufJD/rFrfr3G1F78g9P4XwZKEEuLJE=; b=Z2rwCXRqLhWXHEYPEV1MaDiz4adHlqtiI8wN/3IU5vWxpC5lciRG4bc4xCSemuCgZE qhjyUKKjHuJzOk5dI7VpJEOUCuJ3HIIWBxKGh//Ubzwo3CUYb0AbcEU/3LvRDznDs0wx g876H7tgXdmnIWWGZ9yA/lxBulv/hmWQMMtWnnb1KmrQCePDBZNXqhESupDqxuR7jmD1 h+t2N7Wnc6AFS4xmxSKbUuApx+PAi3t/V8pUsOU6r2wQNEi+UMapPrgtm+Gt9JU/IhTi sc/V/xcXVQMhD3L8R3fNnieLmXANx06Z1uJ/N03TuCbbxxp14RJKE3Xuq6TJOMEARAhI Ip3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778652984; x=1779257784; h=in-reply-to: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=l3Ulf58yT3vhnufJD/rFrfr3G1F78g9P4XwZKEEuLJE=; b=sGW9ymftMAW4jDGT/pbLcgQ/S3CbDwVzOhetWbXv2pvX64ak28AfFzW/dqDfko0C5Y /q7aiE1/MLEFGcDPBbouL7T6zbSzlZum9hZISET7PTIcygFiIxErP6BSfTToPiQP01jC bqIOJN8KAx12HMwDlnw6vgJur42Xl0Fmn0a660jr3sfbUElu/sf/oE6PN/L2XI/i3hsc Jv6SEPTQ0jMam0UVpxN55fh/mM8/GfA54uvb0P6f9TzEAoLELNcCoMQKmH/IOQrOGuC5 IlJzqPoC5RcCl66rfQtuZewCaxsDfW5pduJAE/cXCFpWsbpBdO7/KKOT82HSMFfapEfV JPNA== X-Forwarded-Encrypted: i=1; AFNElJ9TLzIgelh4y1QXs4h7/YOznKpZjybq/TTDh8OLoPAPWI3bi4hvF3jgpTUtfY6kNBMRv8iNHZ80+/vchjw=@vger.kernel.org X-Gm-Message-State: AOJu0YzdWRPpJD4vgucyCoftuffnBdfieGsWcCsuejEW0U5vKCb5k/ol DbdKfGaZYrGEbHhNpqhvZQyTxIWXtxQ4kkdAY4UJYpGnnAaIUV2ymwUmLcTruDyox2uf05JgyML mZzcpYUV6ig/iqwVUKu2X2uLQAhGjwV8RKfS8N+OCMRbHGlPRE9WxPHAGpm+PPIlC+A== X-Gm-Gg: Acq92OELUEvemUnlo07XxelhArVloNvEheLt4xkZntPHbSXi4RASFgXCj7A3G/Vh5hW R6vb13eBYrg2M6rgxevT0V31zqnjFKwCcHfP6Ji0hjyPl27Id7yCfhW9KwQVgnD9EzWXiZlLZuG nNCrmsXR+7dEt8FQ2YIj/iOiH54kZys7sTxrWfs36sVIPDSE8T0sw6zCgHeAvL1Yvb8pzZc4OSi izHzo3bdxQOmFQYu6wY2my4gZ6xZptdFRuYbN7hqRxBpSy4gsTpUiFlFgGpuwagAXpqG3M/4e4w yZUOs9lrSxEI2784c/+l8Ksu6UJkRt890mWTBEvhmuxxccXy6a+kKm7u9oVE7ZLNgKrWVafF3ce mquPSTsxZ8atJfi0sf1L0nRuNrA4CT7OE2cXvm0HlZDmF3M0XghJE X-Received: by 2002:a05:6000:2c0c:b0:441:239e:2bb8 with SMTP id ffacd0b85a97d-45c77e636b8mr2134213f8f.7.1778652984542; Tue, 12 May 2026 23:16:24 -0700 (PDT) X-Received: by 2002:a05:6000:2c0c:b0:441:239e:2bb8 with SMTP id ffacd0b85a97d-45c77e636b8mr2134163f8f.7.1778652984145; Tue, 12 May 2026 23:16:24 -0700 (PDT) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.56.132]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4548ec6be40sm39386098f8f.12.2026.05.12.23.16.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2026 23:16:23 -0700 (PDT) Date: Wed, 13 May 2026 08:16:21 +0200 From: Juri Lelli To: Andrea Righi Cc: Ingo Molnar , Peter Zijlstra , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , 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=us-ascii Content-Disposition: inline In-Reply-To: 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.