From: Sergey Senozhatsky <firstname.lastname@example.org>
To: Petr Mladek <email@example.com>
Cc: Tetsuo Handa <firstname.lastname@example.org>,
Sergey Senozhatsky <email@example.com>,
Sergey Senozhatsky <firstname.lastname@example.org>,
Steven Rostedt <email@example.com>,
John Ogness <firstname.lastname@example.org>,
Andrew Morton <email@example.com>,
Linus Torvalds <firstname.lastname@example.org>,
Subject: Re: [RFC PATCH] printk: Introduce "store now but print later" prefix.
Date: Mon, 4 Mar 2019 23:37:58 +0900 [thread overview]
Message-ID: <20190304143758.GA9036@tigerII.localdomain> (raw)
On (03/04/19 15:23), Petr Mladek wrote:
> > I confirmed that printk_deferred() is not suitable for this purpose, for
> > it suddenly stalls for seconds at random locations flushing pending output
> > accumulated by printk_deferred(). Stalling inside critical section (e.g.
> > RCU read lock held) is what I don't like.
> I still do not see why your async printk should be significantly
> better than printk_deferred(). There is still a random victim
> that would be responsible to flush the messages.
> It might increase the chance that it will get printed from
> normal context. But it also adds the risk that consoles
> will not get handled at all.
> BTW: The comment above printk_deferred() is there for a reason.
> It is a hack that should not be used widely.
> If you convert half printk() calls into a deferred/async
> module, you will just get into another problems. For example,
> not seeing the messages at all, more lost messages, random
> victims would spend even more time with flushing to the console.
The thing with printk_deferred/printk_safe is that it always involves
IRQ->console_unlock()->loop. This thing is not welcome, we need some
other task to hand off printing to badly or we simply hard lockup the
system. I'd say that this probably should be the main reason those
those symbols are not exported.
> For example, I would stop printing allocation failures until
> the currently running OOM killer succeeds in freeing some memory.
> It might print a message about that all further allocation
> failures will not get reported and then another message
> about the success...
I'm all for it.
next prev parent reply other threads:[~2019-03-04 14:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-23 4:42 [RFC PATCH] printk: Introduce "store now but print later" prefix Tetsuo Handa
2019-03-04 3:22 ` Sergey Senozhatsky
2019-03-04 11:40 ` Tetsuo Handa
2019-03-04 12:09 ` Sergey Senozhatsky
2019-03-04 14:23 ` Petr Mladek
2019-03-04 14:37 ` Sergey Senozhatsky [this message]
2019-03-05 1:23 ` Tetsuo Handa
2019-03-05 7:52 ` Sergey Senozhatsky
2019-03-05 12:57 ` Michal Hocko
2019-03-06 10:04 ` Petr Mladek
2019-03-06 14:27 ` Sergey Senozhatsky
2019-03-06 18:24 ` Tetsuo Handa
2019-03-15 10:49 ` Tetsuo Handa
2019-03-20 15:04 ` Petr Mladek
2019-03-20 15:25 ` ratelimit API: was: " Petr Mladek
2019-03-21 8:13 ` Tetsuo Handa
2019-03-21 8:49 ` Michal Hocko
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.