From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Eric Biederman <ebiederm@xmission.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.com>, Pavel Machek <pavel@ucw.cz>,
Andreas Mohr <andi@lisas.de>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads
Date: Wed, 28 Jun 2017 15:42:51 +0200 [thread overview]
Message-ID: <20170628134251.GQ1538@pathway.suse.cz> (raw)
In-Reply-To: <20170608081829.GA442@jagdpanzerIV.localdomain>
On Thu 2017-06-08 17:18:29, Sergey Senozhatsky wrote:
> we still don't have guarantees that printk_kthread will be scheduled on
> a CPU that can run it immediately or anytime in the future, but not too
> late. printk_kthread can even be scheduled on the CPU that has requested
> offloading in the first place (am I wrong on this assumption?). which means
> that printk_kthread may not be able to take over (think of a printk() dump
> from IRQ context). that's the reason why I additionally want to
> console_trylock() for PRINTK_PENDING_PRINTK_OFFLOAD.
>
>
> but console_trylock() is not really reliable. not at all. it's a very fast
> one shot action that most likely will see console_sem still being locked
> but the CPU that has requested offloading. I want something to wait on
> console_sem, that's reliably. and we need woken up (running) printk_kthread
> for that.
>
>
> may be... we can set CPU affinity on printk_kthread before we wake it up?
> place into rq of the CPU that is processing PRINTK_PENDING_PRINTK_OFFLOAD?
>
> or allow it on any CPU but the currently printing CPU.
>
> or have per-CPU printk kthreads and wake_up processes that are already
> bound to specific rq-s. (I know it's ugly, to put it politely. I'm just
> trying different solutions/approaches).
My head is whirling when thinking about all the per-CPU stuff. It is
looking for escape. The way is to keep it as simple as possible.
After all, we should need all this only when there is a flood of
messages. Otherwise, the messages should be handled immediately
within atomic_print_limit.
If there is a flood of messages and we do not sleep inside
console_unlock(), there should always be a new volunteer that
would continue with console flushing.
It the flood stops and the system works, we should have enough
time to recover. If the system stops working during the flood
then I am afraid that even the per-CPU kthreads would not help
much.
Does this makes sense? Or did my head hide some important aspect
again?
Best Regards,
Petr
next prev parent reply other threads:[~2017-06-28 13:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-02 9:03 Sergey Senozhatsky
2017-06-02 9:03 ` [RFC][PATCHv4 1/7] printk: move printk_pending out of per-cpu Sergey Senozhatsky
2017-06-02 9:03 ` [RFC][PATCHv4 2/7] printk: introduce printing kernel SMP threads Sergey Senozhatsky
2017-06-02 9:03 ` [RFC][PATCHv4 3/7] printk: add enforce_emergency parameter Sergey Senozhatsky
2017-06-02 9:03 ` [RFC][PATCHv4 4/7] printk: enable printk offloading Sergey Senozhatsky
2017-06-02 9:03 ` [RFC][PATCHv4 5/7] printk: register PM notifier Sergey Senozhatsky
2017-06-02 9:03 ` [RFC][PATCHv4 6/7] printk: register syscore notifier Sergey Senozhatsky
2017-06-02 9:03 ` [RFC][PATCHv4 7/7] printk: add printk cpumask sysctl Sergey Senozhatsky
2017-06-08 8:18 ` [RFC][PATCHv4 0/7] printk: introduce printing kernel threads Sergey Senozhatsky
2017-06-28 13:42 ` Petr Mladek [this message]
2017-06-29 7:56 ` Sergey Senozhatsky
2017-06-30 12:11 ` Petr Mladek
2017-06-30 12:45 ` Sergey Senozhatsky
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=20170628134251.GQ1538@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=andi@lisas.de \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=jslaby@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®