From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) (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 C5B5A3E2AD3 for ; Fri, 15 May 2026 18:56:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778871371; cv=none; b=lZkNUuhqqb8TiFnEDPUtX67YMPyIVonvQyOLjjD3/gsKawOFiPpS13cCbnxsvWRfXoVzDoLPUPLOSH/p24Gxe6POqR3Ykg9Yqvq9nKbFKD8x/Pc+T4gWIPUaNcd+bmPhErj3jv/PbceIxXstGIVlRC5UyDk6VYDdUfh4KQ2ORzk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778871371; c=relaxed/simple; bh=KjUbBoY2w+rOsdwF+2UTRsnEdQFvVeP68261vsuQTnQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=oDCL+Q6t4hTjJqSicTYVYLulMqk0eYKhZvLZCO3t3ar4nzNFzQ5GwVc2nSj48NQjDPxx2rwlg1litF2mKuxVmSedrEtxdWKx+ad8cfbefsMLYhsz7TJrx7gRb8mLJklaIif7gRRsI+QqD947Q0lBslfgkUczkFG835FIIvlkT4s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf16.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9BB7616049B; Fri, 15 May 2026 18:56:02 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf16.hostedemail.com (Postfix) with ESMTPA id 51C032000E; Fri, 15 May 2026 18:56:00 +0000 (UTC) Date: Fri, 15 May 2026 14:56:08 -0400 From: Steven Rostedt To: Tejun Heo Cc: LKML , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Kyle McMartin Subject: Re: [PATCH v2] sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT Message-ID: <20260515145608.2039b4cf@gandalf.local.home> In-Reply-To: References: <20260515103740.25ccbed8@gandalf.local.home> <20260515143847.543c4b8c@gandalf.local.home> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit X-Rspamd-Server: rspamout07 X-Rspamd-Queue-Id: 51C032000E X-Stat-Signature: 7p86o5484azmafrp4xjg76dnhf8r3hr6 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1+G2GiGH8pbE+vxmQ2fQaZsHHr8L3ikMZU= X-HE-Tag: 1778871360-517402 X-HE-Meta: U2FsdGVkX1/pl2mAKOZhzmDcQjQYq2sKPu2SumlUaF6h7VbxEcLchdsoBdCs02wqdq/Bx0cyjJ9x3s6J0QxCcDVuPF6rNeU2daccyC+c9tt4MzouJSI70oHptlUavezZPDnTfW4uT5iGQi0MUmP7HKF0mlz0IEkQOYss9rZ9NXAwl7aY43GJDx3n8qJVITYGke++Upb8StPvHzIvDu9P9lnLXLjKsMEyCF/SbpZ6b+P9XK9r2Z3RPA3dGktKOch2K426OLnC38t0DbY9+cUOZ94VOusmJ7ezg5QPaEvQ/ZqnX9oOHno5cw5L0QnfHbggixZNEr5PUsOD2kCuE1K9HumVeR7Uqt9z On Fri, 15 May 2026 08:47:49 -1000 Tejun Heo wrote: > Hello, Steven. > > On Fri, May 15, 2026 at 02:38:47PM -0400, Steven Rostedt wrote: > > Hmm, but I'm guessing that it still was long enough to slow down the > > softirq to trigger it again and prevent scheduling? > > Yes, seems that way. I think the load is lower and each softirq invocation > is relatively short (just going through the packets received in the > meantime) but the frequency is higher. I just want to make sure that my analysis is correct. Since only one CPU can initiate the RT_PUSH_IPI. That for this to be a problem, other CPUs need to be constantly running RT tasks for short periods of time so that when the RT task schedules off the CPU, the CPU then initiates the "pull". And it's not that it happens all at once. It's more serialized where the RT tasks are scheduling off at different times to constantly feed the RT_PUSH_IPI logic without seeing that it's already in place. It would require this to happen enough times to keep the overloaded CPU from finishing the softirq until a time when the softirq is scheduled again. And it would maintain this abuse for long enough to trigger the watchdog. Does that fit the scenario of your environment? -- Steve