[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160322075738.GC1759@swordfish>
Date: Tue, 22 Mar 2016 16:57:38 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Jan Kara <jack@...e.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jan Kara <jack@...e.com>, Petr Mladek <pmladek@...e.com>,
Tejun Heo <tj@...nel.org>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
linux-kernel@...r.kernel.org,
Byungchul Park <byungchul.park@....com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async
Hello Jan,
On (03/22/16 07:49), Jan Kara wrote:
> Hi,
>
> On Tue 22-03-16 02:25:28, Sergey Senozhatsky wrote:
> > The patch set is based on slightly updated Jan Kara's patches.
> >
> > This patch set makes printk() completely asynchronous: new messages
> > are getting upended to the kernel printk buffer, but instead of 'direct'
> > printing the actual print job is performed by a dedicated kthread.
> > This has the advantage that printing always happens from a schedulable
> > context and thus we don't lockup any particular CPU or even interrupts.
> >
> > The patch set is against next-20160321
> >
> > the series in total has 3 patches:
> > - printk: Make printk() completely async
> > - printk: Make wake_up_klogd_work_func() async
> > - printk: make console_unlock() async
> >
> > per discussion, "printk: make console_unlock() async" will be posted
> > later on.
>
> Patches look good to me. I don't think you need to mention the
> console_unlock() async patch when it is not part of the series.
thanks.
> BTW, you seemed to have dropped my patch to skip if there are too
> many buffered messages when oops is in progress. Any reason for that?
I did. seems that my box has some problems with emails delivery recently:
http://marc.info/?l=linux-kernel&m=145821214108806
in short,
I'm afraid we can lose valuable data in some cases.
for example
: hardlockup detector with sysctl_hardlockup_all_cpu_backtrace.
:
: static void watchdog_overflow_callback(...)
: {
: ...
: if (is_hardlockup()) {
: ...
: if (sysctl_hardlockup_all_cpu_backtrace &&
: !test_and_set_bit(0, &hardlockup_allcpu_dumped))
: trigger_allbutself_cpu_backtrace();
:
: nmi_panic(regs, msg);
: ...
: }
: ...
: }
:
: trigger_allbutself_cpu_backtrace() can be much more than 100 lines.
: trigger_allbutself_cpu_backtrace() may or may not be implemented via
: NMI. for example arch/sparc/kernel/process_64.c
on a large enough system trigger_allbutself_cpu_backtrace() can easily be more
than 100 lines, and trigger_allbutself_cpu_backtrace() may not be able to print
the backtraces to console (for example this hardlockuped CPU owns the console_sem)
before CPU declares oops_in_progress in nmi_panic()->panic().
-ss
Powered by blists - more mailing lists