On Fri 22-11-13 15:27:11, Andrew Morton wrote:
> On Fri, 8 Nov 2013 11:21:13 +0100 Jan Kara wrote:
>
> > On Fri 08-11-13 00:46:49, Frederic Weisbecker wrote:
> > > On Thu, Nov 07, 2013 at 06:37:17PM -0500, Steven Rostedt wrote:
> > > > On Fri, 8 Nov 2013 00:21:51 +0100
> > > > Frederic Weisbecker
On Fri, 8 Nov 2013 11:21:13 +0100 Jan Kara wrote:
> On Fri 08-11-13 00:46:49, Frederic Weisbecker wrote:
> > On Thu, Nov 07, 2013 at 06:37:17PM -0500, Steven Rostedt wrote:
> > > On Fri, 8 Nov 2013 00:21:51 +0100
> > > Frederic Weisbecker wrote:
> > > >
> > > > Offloading to a workqueue would b
Hi!
> > > > > Reviewed-by: Steven Rostedt
> > > > > Signed-off-by: Jan Kara
> > > >
> > > > When a message takes tens of seconds to be printed, it usually means
> > > > we are in trouble somehow :)
> > > > I wonder what printk source can trigger such a high volume.
> > > Machines with tens of
On Mon 11-11-13 22:54:15, Pavel Machek wrote:
> Hi!
>
> > > > A CPU can be caught in console_unlock() for a long time (tens of seconds
> > > > are reported by our customers) when other CPUs are using printk heavily
> > > > and serial console makes printing slow. Despite serial console drivers
> >
Hi!
> > > A CPU can be caught in console_unlock() for a long time (tens of seconds
> > > are reported by our customers) when other CPUs are using printk heavily
> > > and serial console makes printing slow. Despite serial console drivers
> > > are calling touch_nmi_watchdog() this triggers softloc
On Fri 08-11-13 00:46:49, Frederic Weisbecker wrote:
> On Thu, Nov 07, 2013 at 06:37:17PM -0500, Steven Rostedt wrote:
> > On Fri, 8 Nov 2013 00:21:51 +0100
> > Frederic Weisbecker wrote:
> > >
> > > Offloading to a workqueue would be perhaps better, and writing to the
> > > serial
> > > console
On Thu, Nov 07, 2013 at 06:37:17PM -0500, Steven Rostedt wrote:
> On Fri, 8 Nov 2013 00:21:51 +0100
> Frederic Weisbecker wrote:
>
> > Ok I see now.
> >
> > But then this irq_work based solution won't work if, say, you run in full
> > dynticks
> > mode. Also the hook on the timer interrupt is
On Thu, Nov 07, 2013 at 06:37:17PM -0500, Steven Rostedt wrote:
> On Fri, 8 Nov 2013 00:21:51 +0100
> Frederic Weisbecker wrote:
> >
> > Offloading to a workqueue would be perhaps better, and writing to the serial
> > console could then be done with interrupts enabled, preemptible context,
> > e
On Fri, 8 Nov 2013 00:21:51 +0100
Frederic Weisbecker wrote:
> Ok I see now.
>
> But then this irq_work based solution won't work if, say, you run in full
> dynticks
> mode. Also the hook on the timer interrupt is something that I wish we get rid
> of on archs that can trigger self-IPIs.
Do w
On Thu, Nov 07, 2013 at 11:57:33PM +0100, Jan Kara wrote:
> On Thu 07-11-13 23:43:52, Frederic Weisbecker wrote:
> > 2013/11/7 Jan Kara :
> > > A CPU can be caught in console_unlock() for a long time (tens of seconds
> > > are reported by our customers) when other CPUs are using printk heavily
> >
On Thu, 7 Nov 2013 23:43:52 +0100
Frederic Weisbecker wrote:
> When a message takes tens of seconds to be printed, it usually means
> we are in trouble somehow :)
> I wonder what printk source can trigger such a high volume.
The only ones that I'm aware of is the prints from sysrq. Which
includ
On Thu 07-11-13 23:43:52, Frederic Weisbecker wrote:
> 2013/11/7 Jan Kara :
> > A CPU can be caught in console_unlock() for a long time (tens of seconds
> > are reported by our customers) when other CPUs are using printk heavily
> > and serial console makes printing slow. Despite serial console dri
2013/11/7 Jan Kara :
> A CPU can be caught in console_unlock() for a long time (tens of seconds
> are reported by our customers) when other CPUs are using printk heavily
> and serial console makes printing slow. Despite serial console drivers
> are calling touch_nmi_watchdog() this triggers softloc
A CPU can be caught in console_unlock() for a long time (tens of seconds
are reported by our customers) when other CPUs are using printk heavily
and serial console makes printing slow. Despite serial console drivers
are calling touch_nmi_watchdog() this triggers softlockup warnings
because interrup
On Wed, 21 Aug 2013 10:08:31 +0200
Jan Kara wrote:
> A CPU can be caught in console_unlock() for a long time (tens of seconds
> are reported by our customers) when other CPUs are using printk heavily
> and serial console makes printing slow. Despite serial console drivers
> are calling touch_nmi_
A CPU can be caught in console_unlock() for a long time (tens of seconds
are reported by our customers) when other CPUs are using printk heavily
and serial console makes printing slow. Despite serial console drivers
are calling touch_nmi_watchdog() this triggers softlockup warnings
because interrup
On Thu, 15 Aug 2013 09:52:51 +0200
Jan Kara wrote:
> > > +/*
> > > + * How much characters can we print in one call of printk before
> > > offloading
> > > + * printing work
> > > + */
> > > +#define MAX_PRINTK_CHARS 1000
> >
> > This really needs to be configurable. 1000 may be good for you,
On Wed 14-08-13 21:38:18, Steven Rostedt wrote:
> On Wed, 14 Aug 2013 15:28:27 +0200
> Jan Kara wrote:
>
> > A CPU can be caught in console_unlock() for a long time (tens of seconds
> > are reported by our customers) when other CPUs are using printk heavily
> > and serial console makes printing s
On Wed, 14 Aug 2013 15:28:27 +0200
Jan Kara wrote:
> A CPU can be caught in console_unlock() for a long time (tens of seconds
> are reported by our customers) when other CPUs are using printk heavily
> and serial console makes printing slow. Despite serial console drivers
> are calling touch_nmi_
A CPU can be caught in console_unlock() for a long time (tens of seconds
are reported by our customers) when other CPUs are using printk heavily
and serial console makes printing slow. Despite serial console drivers
are calling touch_nmi_watchdog() this triggers softlockup warnings
because interrup
20 matches
Mail list logo
