[PATCH] printk: do not flush the logbuf into console driver in interrupt

[PATCH] printk: do not flush the logbuf into console driver in interrupt

[Liu, Chuansheng]

From: liu chuansheng <chuansheng.liu@intel.com>
Subject: [PATCH] printk: do not flush the logbuf into console driver in interrupt

When irq handle tried to call printk, and it also has the chance to obtain the console sem,
then flush the log buf to console driver,but the console driver often give several ms latency
or more when much data in log buf existed, it will delay the irq handle.

The solution is when calling the printk in interrupt, just write the chars into log buf,
and expect other threads to flush it into console driver.

Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>

diff --git a/kernel/printk.c b/kernel/printk.c index b663c2c..99959e1 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -804,7 +804,8 @@ static int console_trylock_for_printk(unsigned int cpu)
                 * the buffer. We need to hold the console semaphore
                 * in order to do this test safely.
                 */
-               if (!can_use_console(cpu)) {
+               if (!can_use_console(cpu) ||
+                       (in_interrupt() && (!oops_in_progress))) {
                        console_locked = 0;
                        wake = 1;
                        retval = 0;

Re: [PATCH] printk: do not flush the logbuf into console driver in interrupt

[Peter Zijlstra]

On Thu, 2012-05-17 at 07:46 +0000, Liu, Chuansheng wrote:
> From: liu chuansheng <chuansheng.liu@intel.com>
> Subject: [PATCH] printk: do not flush the logbuf into console driver in interrupt
> 
> When irq handle tried to call printk, and it also has the chance to obtain the console sem,
> then flush the log buf to console driver,but the console driver often give several ms latency
> or more when much data in log buf existed, it will delay the irq handle.
> 
> The solution is when calling the printk in interrupt, just write the chars into log buf,
> and expect other threads to flush it into console driver.
> 
> Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
> 
> diff --git a/kernel/printk.c b/kernel/printk.c index b663c2c..99959e1 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -804,7 +804,8 @@ static int console_trylock_for_printk(unsigned int cpu)
>                  * the buffer. We need to hold the console semaphore
>                  * in order to do this test safely.
>                  */
> -               if (!can_use_console(cpu)) {
> +               if (!can_use_console(cpu) ||
> +                       (in_interrupt() && (!oops_in_progress))) {
>                         console_locked = 0;
>                         wake = 1;
>                         retval = 0;

Uhm no.. I would very much like to get my OOPSes from interrupt context
to make it out to the console.

RE: [PATCH] printk: do not flush the logbuf into console driver in interrupt

[Liu, Chuansheng]

> Uhm no.. I would very much like to get my OOPSes from interrupt context to
> make it out to the console.
(!oops_in_progress) this condition is in the patch, it should cover OOPSes output
to console in interrupt context, I tested this case just now.

> -----Original Message-----
> From: Peter Zijlstra [mailto:peterz@infradead.org]
> Sent: Thursday, May 17, 2012 5:31 PM
> To: Liu, Chuansheng
> Cc: linux-kernel@vger.kernel.org; tglx@linutronix.de; Yanmin Zhang
> <yanmin_zhang@linux.intel.com> (yanmin_zhang@linux.intel.com)
> Subject: Re: [PATCH] printk: do not flush the logbuf into console driver in
> interrupt
> 
> On Thu, 2012-05-17 at 07:46 +0000, Liu, Chuansheng wrote:
> > From: liu chuansheng <chuansheng.liu@intel.com>
> > Subject: [PATCH] printk: do not flush the logbuf into console driver
> > in interrupt
> >
> > When irq handle tried to call printk, and it also has the chance to
> > obtain the console sem, then flush the log buf to console driver,but
> > the console driver often give several ms latency or more when much data in
> log buf existed, it will delay the irq handle.
> >
> > The solution is when calling the printk in interrupt, just write the
> > chars into log buf, and expect other threads to flush it into console driver.
> >
> > Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
> >
> > diff --git a/kernel/printk.c b/kernel/printk.c index b663c2c..99959e1
> > 100644
> > --- a/kernel/printk.c
> > +++ b/kernel/printk.c
> > @@ -804,7 +804,8 @@ static int console_trylock_for_printk(unsigned int
> cpu)
> >                  * the buffer. We need to hold the console semaphore
> >                  * in order to do this test safely.
> >                  */
> > -               if (!can_use_console(cpu)) {
> > +               if (!can_use_console(cpu) ||
> > +                       (in_interrupt() && (!oops_in_progress))) {
> >                         console_locked = 0;
> >                         wake = 1;
> >                         retval = 0;
> 
> Uhm no.. I would very much like to get my OOPSes from interrupt context to
> make it out to the console.