From: Peter Zijlstra <peterz@infradead.org>
To: Phil Auld <pauld@redhat.com>
Cc: Chen Yu <yu.c.chen@intel.com>, Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Biju Das <biju.das.jz@bp.renesas.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
linux-kernel@vger.kernel.org, Tim Chen <tim.c.chen@intel.com>,
Chen Yu <yu.chen.surf@gmail.com>
Subject: Re: [PATCH] sched/fair: Use printk_deferred instead of printk in pick_eevdf()
Date: Tue, 10 Oct 2023 16:12:44 +0200 [thread overview]
Message-ID: <20231010141244.GM377@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20231010122600.GA477540@lorien.usersys.redhat.com>
On Tue, Oct 10, 2023 at 08:26:00AM -0400, Phil Auld wrote:
> > No.. I detest printk_deferred with a passion. This is effectively a WARN
> > and we don't do silly buggers for them either.
> >
>
> Sure, printk_deferred is not ideal, but is getting this message in the right
> order worth locking up people's machines? Not sure you get the message at
> all when that happens. I have to dig the code location out of the crash
> dump to find which sched warning fired and took down the (usually virtual)
> machine.
Same thing with WARN(), we don't have a silly bugger version of that
either. Just use a sane printk() / console or whatever.
Virt stuff has perfectly functional serial consoles that works just fine
and don't lock up the machine -- mostly. Use my early_printk hacks if
you want something reliable:
https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=debug/experimental
Boot with: "earlyprintk=serial,ttyS0,115200 force_early_printk". And all
will be well.
The fact that crashdump is more reliable than printk is a *BIG* problem
and the only solution is fixing printk() (people are sorta working on
that). We should not try and work around this problem.
I fundamentally despise the delayed stuff, I've had countless insteances
where delaying output means you have no output because the machine is
dead.
next prev parent reply other threads:[~2023-10-10 14:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 3:25 [PATCH] sched/fair: Use printk_deferred instead of printk in pick_eevdf() Chen Yu
2023-10-10 7:59 ` Peter Zijlstra
2023-10-10 12:26 ` Phil Auld
2023-10-10 14:12 ` Peter Zijlstra [this message]
2023-10-11 10:27 ` Chen Yu
2023-10-11 10:30 ` Chen Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231010141244.GM377@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=biju.das.jz@bp.renesas.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mingo@redhat.com \
--cc=pauld@redhat.com \
--cc=tim.c.chen@intel.com \
--cc=vincent.guittot@linaro.org \
--cc=yu.c.chen@intel.com \
--cc=yu.chen.surf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.