From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 6E0A4346FA7 for ; Wed, 20 May 2026 19:37:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779305828; cv=none; b=EXgi6y+9bvcE7p4ye/XENxussOElKWVfrcSHLL2JHiaoZBK4UAGgPZU3tom0hXhQcklqC6NOCT8GdpgJyPFMz4bHDhLuxvkzB7OdLWfaLTJSRx8It3vU121oOpHvVrI5R/rFJj7kMPEMDH/Nk+nI7sXwqNhaSLnIkORLV3NWwoA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779305828; c=relaxed/simple; bh=VoxVh8IjeyEBqFZppSN+vkks65yEc8hCIbFPJ1VPvK4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WXhhtJcP9q8JQ/QeSG2iAlRzTxonBbEJxNgYtDDWtsAxAYBbcvLJH0q4ejNz1lefANySYefiuYCRsoPo0E6ERl4vQU4M0mHFD7Dwapx4L5DVeTAqgfQhM/bSIsHxfxC/WtsXXwHXuBmHh5mp2g5lq2XMPBF//Ze7hGw6hCy8NNk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ee3RRmiI; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ee3RRmiI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE0DB1F000E9; Wed, 20 May 2026 19:37:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779305827; bh=Yx28lySZFKCVR4ZAJqhaEMVRMSLbh9rr5ODgOwUv4Wk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Ee3RRmiIVJKTcU3GR6iRUpYgy/JO4nmhbOlidsTnlWSsGz8X1tcvklKVdcIRiW9lD 0wpXR28mGeatgwfK4pXx+QY6SFoM4e6c7e/VkDD1n0HJ7lbVPxEXiE03OwQKMPBLKl n7LPJf0YK7Dm8SmDdC0aO7ibOCCsBjsTNVrwZDASJY/IZXE6uN0TX0ELw33CfRqQ80 aVAsXQCN+fN9B7iaJ1TjpXWH6xjwa7YwRdlk7UOyqRQ4P2wUBo0N2zdMvF6qcEOpi0 OrsEfwnsSZVkGLZ6lfRmOvevIcweIZpBirb94MZa3uUcbaYO5xkoo8sMKLAf/y6utN pp2CkSOj+1ncg== Date: Wed, 20 May 2026 09:37:06 -1000 From: Tejun Heo To: Steven Rostedt Cc: Shrikanth Hegde , Valentin Schneider , LKML , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , K Prateek Nayak , Kyle McMartin Subject: Re: [PATCH v2] sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT Message-ID: References: <20260515103740.25ccbed8@gandalf.local.home> <61203cdb-af98-47e6-bb70-78af7f0f1cbc@linux.ibm.com> <20260520125226.50b83e76@gandalf.local.home> <310c1f04-562e-4e81-9d39-0f28e1cc414c@linux.ibm.com> <20260520150244.0653000a@gandalf.local.home> 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: <20260520150244.0653000a@gandalf.local.home> Hello, On Wed, May 20, 2026 at 03:02:44PM -0400, Steven Rostedt wrote: > But it should still be making forward progress. The IPI handler is very short. > > Are the other CPUs running very short lived RT tasks that constantly > trigger the IPI push logic? I mean it would need to run a lot of RT > tasks that keep going to sleep to cause a IPI storm to trigger. I don't know for sure. At lower load level, there seem to a bit more than 1000 mpi3 irqs. The stalls were happening when load level was pushed up due to maintenance going through the region. Let's be aggressive and say that the rate was four times and each IRQ triggers the irq thread to be woken up and go back to sleep. That'd be a transition out of RT every 250us across the system. That's a lot but I'm not sure that's enough to stall for tens of seconds. So, I'm not sure. Thanks. -- tejun