On Tue 01-03-16 18:22:25, Denys Vlasenko wrote:
> On Mon, Oct 26, 2015 at 5:52 AM, Jan Kara wrote:
> > This patch implements a mechanism where after printing specified number
> > of characters (tunable as a kernel parameter printk.offload_chars), CPU
> > doing printing asks for help by waking up o
On Mon, Oct 26, 2015 at 5:52 AM, Jan Kara wrote:
> This patch implements a mechanism where after printing specified number
> of characters (tunable as a kernel parameter printk.offload_chars), CPU
> doing printing asks for help by waking up one of dedicated kthreads. As
> soon as the printing CPU
On Wed 06-01-16 15:48:36, Sergey Senozhatsky wrote:
> On (01/05/16 15:37), Jan Kara wrote:
> > > How about setting 'sync_print' to 'true' in...
> > > bust_spinlocks() /* only set to true */
> > > or
> > > console_verbose() /* um... may be... */
> > > or
> > > having a separate one-liner for t
On (01/06/16 11:21), Jan Kara wrote:
[..]
> >
> > or like this on another setup ([k|u]_ts updated to u64)
> >
> > # cat /proc/1/time_in_console_unlock
> > kern:[12.755920] user:[38.367332]
>
> So maybe that is worth addressing if it bothers you but please as a
> separate patch set. This seems fa
On Wed 06-01-16 17:36:53, Sergey Senozhatsky wrote:
> On (01/06/16 12:38), Sergey Senozhatsky wrote:
> > On (01/05/16 15:48), Jan Kara wrote:
> > > > [..]
> > > > > cond_resched() does its job there, of course. well, a user process
> > > > > still can
> > > > > do a lot of call_console_drivers() c
On (01/06/16 12:38), Sergey Senozhatsky wrote:
> On (01/05/16 15:48), Jan Kara wrote:
> > > [..]
> > > > cond_resched() does its job there, of course. well, a user process
> > > > still can
> > > > do a lot of call_console_drivers() calls. may be we can check who is
> > > > calling
> > > > consol
On (01/05/16 15:37), Jan Kara wrote:
> > How about setting 'sync_print' to 'true' in...
> > bust_spinlocks() /* only set to true */
> > or
> > console_verbose() /* um... may be... */
> > or
> > having a separate one-liner for that
> >
> > void console_panic_mode(void)
> > {
> > sync_prin
Hello,
On (01/05/16 15:48), Jan Kara wrote:
> > [..]
> > > cond_resched() does its job there, of course. well, a user process still
> > > can
> > > do a lot of call_console_drivers() calls. may be we can check who is
> > > calling
> > > console_unlock() and if we have "!printk_sync && !oops_in_p
Hello,
On (01/05/16 15:37), Jan Kara wrote:
> Hi,
>
> On Wed 23-12-15 10:54:49, Sergey Senozhatsky wrote:
> > slowly looking through the patches.
>
> Back from Christmas vacation...
>
> > How about setting 'sync_print' to 'true' in...
> > bust_spinlocks() /* only set to true */
> > or
> > c
On Thu 31-12-15 13:58:59, Sergey Senozhatsky wrote:
> On (12/31/15 12:13), Sergey Senozhatsky wrote:
> [..]
> > cond_resched() does its job there, of course. well, a user process still can
> > do a lot of call_console_drivers() calls. may be we can check who is calling
> > console_unlock() and if w
Hi,
On Wed 23-12-15 10:54:49, Sergey Senozhatsky wrote:
> slowly looking through the patches.
Back from Christmas vacation...
> How about setting 'sync_print' to 'true' in...
> bust_spinlocks() /* only set to true */
> or
> console_verbose() /* um... may be... */
> or
> having a separate o
On (12/31/15 12:13), Sergey Senozhatsky wrote:
[..]
> cond_resched() does its job there, of course. well, a user process still can
> do a lot of call_console_drivers() calls. may be we can check who is calling
> console_unlock() and if we have "!printk_sync && !oops_in_progress" (or just
> printk_
On (12/31/15 11:44), Sergey Senozhatsky wrote:
> On (12/22/15 14:47), Jan Kara wrote:
> [..]
> > +int printk_deferred(const char *fmt, ...)
> > +{
> > + va_list args;
> > + int r;
> > +
> > + va_start(args, fmt);
> > + r = vprintk_emit(0, LOGLEVEL_SCHED, NULL, 0, fmt, args);
> > + va_end(
Hello,
On (12/22/15 14:47), Jan Kara wrote:
[..]
> +int printk_deferred(const char *fmt, ...)
> +{
> + va_list args;
> + int r;
> +
> + va_start(args, fmt);
> + r = vprintk_emit(0, LOGLEVEL_SCHED, NULL, 0, fmt, args);
> + va_end(args);
> +
> + return r;
> +}
[..]
> @@ -1803
On (12/23/15 12:57), Sergey Senozhatsky wrote:
[..]
> > > can we replace this oops_in_progress check with something more reliable?
> > >
> > > CPU0CPU1 - CPUN
> > > panic()
> > > local_irq_disable()executing foo() with irqs disabled,
> > > console_
nel.org
> Subject: Re: [PATCH 1/7] printk: Hand over printing to console if printing
> too long
> User-Agent: Mutt/1.5.24 (2015-08-30)
>
> On (12/23/15 10:54), Sergey Senozhatsky wrote:
> > On (12/22/15 14:47), Jan Kara wrote:
> > [..]
> > > @@ -1803,10
On (12/23/15 10:54), Sergey Senozhatsky wrote:
> On (12/22/15 14:47), Jan Kara wrote:
> [..]
> > @@ -1803,10 +1869,24 @@ asmlinkage int vprintk_emit(int facility, int level,
> > logbuf_cpu = UINT_MAX;
> > raw_spin_unlock(&logbuf_lock);
> > lockdep_on();
> > + /*
> > +* By default
Hi,
slowly looking through the patches.
On (12/22/15 14:47), Jan Kara wrote:
[..]
> @@ -1803,10 +1869,24 @@ asmlinkage int vprintk_emit(int facility, int level,
> logbuf_cpu = UINT_MAX;
> raw_spin_unlock(&logbuf_lock);
> lockdep_on();
> + /*
> + * By default we print me
On (12/22/15 14:47), Jan Kara wrote:
[..]
> Thanks for looking into my patches and sorry for replying with a delay. As
> I wrote in my previous email [1] even the referenced patches are not quite
> enough. Over last few days I have worked on redoing the stuff as we
> discussed with Linus and Andrew
On Thu 10-12-15 23:52:51, Sergey Senozhatsky wrote:
> Hello,
>
> *** in this email and in every later emails ***
> Sorry, if I messed up with Cc list or message-ids. It's suprisingly
> hard to jump in into a loop that has never been in your inbox. It took
> some `googling' effort.
>
> I haven
On (12/11/15 13:27), Sergey Senozhatsky wrote:
[..]
> > static bool cpu_stop_printing(int printed_chars)
> > {
> > /* Oops? Print everything now to maximize chances user will see it
> > */
> > if (oops_in_progress)
> > return false;
> > if (!printk_offload_c
On (12/10/15 23:52), Sergey Senozhatsky wrote:
> > Currently, console_unlock() prints messages from kernel printk buffer to
> > console while the buffer is non-empty. When serial console is attached,
> > printing is slow and thus other CPUs in the system have plenty of time
> > to append new messag
On (12/10/15 23:52), Sergey Senozhatsky wrote:
>
> I think we better use raw_spin_lock as a print_lock; and, apart from that,
> seems that we don't re-init in zap_lock(). So I ended up with the following
> patch on top of yours (to be folded):
>
> - use raw_spin_lock
> - do not forget to re-init
Hello,
*** in this email and in every later emails ***
Sorry, if I messed up with Cc list or message-ids. It's suprisingly
hard to jump in into a loop that has never been in your inbox. It took
some `googling' effort.
I haven't tested the patch set yet, I just 'ported' it to linux-next.
I rev
From: Jan Kara
Currently, console_unlock() prints messages from kernel printk buffer to
console while the buffer is non-empty. When serial console is attached,
printing is slow and thus other CPUs in the system have plenty of time
to append new messages to the buffer while one CPU is printing. Th
25 matches
Mail list logo
