From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) (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 83B9929D26B for ; Wed, 20 May 2026 19:02:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779303752; cv=none; b=pWjWOOCGuqKIPqYGXhnJK5zD4deUIlNzy2TQ5psDVeUMn8Hmc6dyBCvZGeEemZROfaJA6MgOF8VwM8UklkkNizUdJ+XyoLug8PL0FyNkx2XnMwbYbn5EuPH7JXmv/burH+1Mq7nszx4HTq7RdAMIvnEjurQ/UupxCSwSqRk/WF8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779303752; c=relaxed/simple; bh=x/QBj5v33wZdThtGBTWq7UzI5+Po/8GEN5IC/M8FKZQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Yk0ZKOV11n2JZnO6xvdxpMM0Udf8XCvgCe3qBj/q9vkSdReHKtg9zX8OJVWkQyKW0PBIC4PzY4tb31c/wMEj5qUIQAvunvQ1NWZ3ktreBgXHOQKqLZFlR3yDRapLg6YtjzdnSFEdWUZKajhfZdH3/Oheo1ZdcabiLeoM12t53kk= 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.11 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 omf03.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2D8391201BF; Wed, 20 May 2026 19:02:28 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf03.hostedemail.com (Postfix) with ESMTPA id 8E3CC6000A; Wed, 20 May 2026 19:02:25 +0000 (UTC) Date: Wed, 20 May 2026 15:02:44 -0400 From: Steven Rostedt To: Tejun Heo 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: <20260520150244.0653000a@gandalf.local.home> In-Reply-To: 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> 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-Queue-Id: 8E3CC6000A X-Stat-Signature: p7emncapgobkyzneiekx7b8hod1cadiy X-Rspamd-Server: rspamout01 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1/+f25Hukwi8PblmPIBU1zNqVJ/sfvO/U0= X-HE-Tag: 1779303745-904266 X-HE-Meta: U2FsdGVkX19hOVdVYpZSUrlnB1pOPpcO2IBZfTwiv7YGNEjBTTvRH6XSuiNWm0t5Wdvb0e0BjuO+J1FVs/xg5WTilmSNQwx2dIyLLkniaReTn0tHZw30XJd0x9kWTeuMc9UVoXIouW/xD8Kso9VeoUn8cvw7JRkPAkYua5oZTEHoZrpoPlHpQTJebbBeBeMF2cdwI8lLDrcYkqTCCWHK0eE2JgNI9D+Mk3mpilYaMl3UYf6cuO4+bDnB6HkPAxESZTX3jnufrYX9zwD7M3pesvDthU4PMkKyyh+kCuZl3//WnVAcmBeIERBzV6YywFVGMWfQzUSNIQz7E5ceER6WbSkBEFbxjo9ud8jGhyY2PltgyO0Kkb4Fpg== On Wed, 20 May 2026 08:09:04 -1000 Tejun Heo wrote: > On Wed, May 20, 2026 at 10:34:35PM +0530, Shrikanth Hegde wrote: > > By any chance it is running with preempt=none/voluntary? > > If so it might never call schedule until it goes back to user space. > > I think this might be it. In the production dump, the locked up cpus were > often running btrfs compression / decompression. The kernel is PREEMPT_NONE > and while that path has resched_curr()'s, with high enough irq frequency, it > wouldn't be that difficult to catch the cpu enough times before it reaches > the resched point. 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. -- Steve