From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 B85A136A022 for ; Fri, 12 Jun 2026 06:52:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781247147; cv=none; b=nJpqa51KlOKiH4+q0SjFThC27bGAcTnMKpRKkzpZNLZy3DRVVHwFcIZKVlTKzEz22g1oLivmt7Bx+7b1TMrsdwNTQq8Bt9CONqDsOGDYkECqAecOCaiQ5rQsUkDV+/+xAdwgjvCcns+wEiMbaYMHCgDqC2NLsFO2wRMBqz9RHyU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781247147; c=relaxed/simple; bh=Csq2fa6QMldF/0nQfEhVMGLDqYU93e9GNZpJ1H55QOM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QB60kV2DweKVVmlhZAg+ggulmu585lcp3VCJq4U1ZjkhOc7HIDf06DKqlq3ehugD2imt1Bro2kt22BFbFNgv4MkwiRzs7N/QSlXgCacubGZFTEh5TgY7gcv6fzb1aaqnw+UQQk/H7r5ZeNXkIylcA3RlPTEudqv1dt8BGxvHbVU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=iVs822ve; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="iVs822ve" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=wYZ7eA2dJeBWJlCj9ZKF2MmhtvyPWx0QJfgG0Qx5YB8=; b=iVs822vebika7EYPozl3TIqg1q Za7hLVkVugVacr7Ya52VwviA9z5ZI0V8WJHLjhfyfcCa2ZYItPbcuMzUGQSacvrNKEEwP3YDNIhiB FNTurhQFzksMkBz7f8unqcS+z+gHYUGjmrF2l0IQaZ3PUJwHyN3MneFIJ6VdGfbZsPD3uIoEia+Z4 KXsdfd811nIS6UqObE1Xa3Q91Lj40Zc056G+nk9DUvT8hAH+mh+2Kq4R7NWywhyV8CW1mvhdbuKQF X3eJ1WmcDolgWSjfFqB7+iZ2r/Wtt0fRKdEH3y83FNcycK0/Jts32EL7+nabAmemNcCRXw1s+EFjD 1g8yi7tw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wXvka-00000003I3Z-2VZ4; Fri, 12 Jun 2026 06:52:21 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 8672E300673; Fri, 12 Jun 2026 08:52:20 +0200 (CEST) Date: Fri, 12 Jun 2026 08:52:20 +0200 From: Peter Zijlstra To: Rik van Riel Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, vschneid@redhat.com Subject: Re: [PATCH 0/9] sched: make WARN_ON under rq->lock deadlock-safe (SCHED_WARN_ON) Message-ID: <20260612065220.GO187714@noisy.programming.kicks-ass.net> References: <20260611021416.910555-1-riel@surriel.com> <20260611074344.GG48970@noisy.programming.kicks-ass.net> <20260611191922.GK187714@noisy.programming.kicks-ass.net> <91b346ee1dfe88390acb462c9c1a8cb8dc3c2b05.camel@surriel.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: <91b346ee1dfe88390acb462c9c1a8cb8dc3c2b05.camel@surriel.com> On Thu, Jun 11, 2026 at 09:53:45PM -0400, Rik van Riel wrote: > On Thu, 2026-06-11 at 21:19 +0200, Peter Zijlstra wrote: > > > > Myself, I almost exclusively run with earlycon serial and force > > printk > > to be early_printk() (effectively not using printk at all). This > > works > > perfectly fine and is the most reliable thing ever. I can push out > > characters to the UART from any context. > > > Great for development, not so good for production. > > When something like an OOM kill happens, the amount > of data printed by the kernel can take a long time > to get flushed out a serial port. > > In fact, it can take long enough to cause things > like RCU stalls and soft lockups, and break > workloads that way. > > Having the serial console deferred allows those > systems to survive. > > If the system crashes before the messages were sent > out the serial port, the dmesg buffer will be in > the vmcore, and get extracted by the crash analysis > tooling. > > It sounds like the printk people may be right with > making that behavior an option, since different > scenarios require different behavior. I've not hit OOM in a decade or so; I've no idea how much silly nonsense it spouts. The example the printk people have used for a long while is booting with a million block devices, apparently that generates insane amount of boot noise -- another problem I don't have :-) Anyway, one solution there is to create a threshold and say ERR and above go directly to atomic console while everything below goes into the buffer and gets spooled out later on the non-atomic variant. This way all your WARN/BUG and other useful bits actually hit the wire when you need them, and the useless verbiage goes into the bin for later. Anyway, all this is stuff that seems trivially solvable.