On Thu 2020-10-01 09:15:39, Rasmus Villemoes wrote:
> On 30/09/2020 15.35, Steven Rostedt wrote:
> > On Wed, 30 Sep 2020 10:06:24 +0200
> > Rasmus Villemoes wrote:
> >
> >> True. But remember that printk is called from _everywhere_, with all
> >> sorts of locks held and/or preemption disabled or
On 30/09/2020 15.35, Steven Rostedt wrote:
> On Wed, 30 Sep 2020 10:06:24 +0200
> Rasmus Villemoes wrote:
>
>> True. But remember that printk is called from _everywhere_, with all
>> sorts of locks held and/or preemption disabled or whatnot, and every
>> cycle spent in printk makes those windows
From: Steven Rostedt
> Sent: 30 September 2020 14:36
>
> On Wed, 30 Sep 2020 10:06:24 +0200
> Rasmus Villemoes wrote:
>
> > True. But remember that printk is called from _everywhere_, with all
> > sorts of locks held and/or preemption disabled or whatnot, and every
> > cycle spent in printk make
On Wed, 30 Sep 2020 10:06:24 +0200
Rasmus Villemoes wrote:
> True. But remember that printk is called from _everywhere_, with all
> sorts of locks held and/or preemption disabled or whatnot, and every
> cycle spent in printk makes those windows wider. Doubling the cost of
> every single printk by
On 2020-09-30, Petr Mladek wrote:
>> Doubling the cost of every single printk by unconditionally doing
>> vsnprintf() twice is a bad idea.
>
> I would prefer to solve this when there are real life problems.
> printk() should not get called in performance sensitive paths in
> the first place.
>
> W
On Wed 2020-09-30 10:06:24, Rasmus Villemoes wrote:
> On 25/09/2020 10.28, Petr Mladek wrote:
> > On Thu 2020-09-24 14:32:49, Rasmus Villemoes wrote:
> >> On 24/09/2020 11.54, Rasmus Villemoes wrote:
> >>> On 23/09/2020 17.11, Petr Mladek wrote:
> On Tue 2020-09-22 17:44:14, John Ogness wrote:
On 25/09/2020 10.28, Petr Mladek wrote:
> On Thu 2020-09-24 14:32:49, Rasmus Villemoes wrote:
>> On 24/09/2020 11.54, Rasmus Villemoes wrote:
>>> On 23/09/2020 17.11, Petr Mladek wrote:
On Tue 2020-09-22 17:44:14, John Ogness wrote:
> vprintk_store() is using a single static buffer as a te
On Thu 2020-09-24 14:32:49, Rasmus Villemoes wrote:
> On 24/09/2020 11.54, Rasmus Villemoes wrote:
> > On 23/09/2020 17.11, Petr Mladek wrote:
> >> On Tue 2020-09-22 17:44:14, John Ogness wrote:
> >>> vprintk_store() is using a single static buffer as a temporary
> >>> sprint buffer for the message
On Thu 2020-09-24 11:49:06, Rasmus Villemoes wrote:
> On 24/09/2020 10.53, Sergey Senozhatsky wrote:
> > On (20/09/24 10:45), Petr Mladek wrote:
> >> On Thu 2020-09-24 14:40:58, Sergey Senozhatsky wrote:
> >>> On (20/09/23 17:11), Petr Mladek wrote:
>
> AFAIK, there is one catch. We need
On Thu 2020-09-24 18:06:53, Sergey Senozhatsky wrote:
> On (20/09/24 10:54), Petr Mladek wrote:
> > > Just a question:
> > >
> > > Can dynamic_textbuf be a PER_CPU array of five textbuf[1024] buffers
> > > (for normal printk, nmi, hard irq, soft irq and one extra buffer for
> > > recursive printk
On 24/09/2020 11.54, Rasmus Villemoes wrote:
> On 23/09/2020 17.11, Petr Mladek wrote:
>> On Tue 2020-09-22 17:44:14, John Ogness wrote:
>>> vprintk_store() is using a single static buffer as a temporary
>>> sprint buffer for the message text. This will not work once
>>> @logbuf_lock is removed. Re
On 23/09/2020 17.11, Petr Mladek wrote:
> On Tue 2020-09-22 17:44:14, John Ogness wrote:
>> vprintk_store() is using a single static buffer as a temporary
>> sprint buffer for the message text. This will not work once
>> @logbuf_lock is removed. Replace the single static buffer with a
>> pool of bu
On 24/09/2020 10.53, Sergey Senozhatsky wrote:
> On (20/09/24 10:45), Petr Mladek wrote:
>> On Thu 2020-09-24 14:40:58, Sergey Senozhatsky wrote:
>>> On (20/09/23 17:11), Petr Mladek wrote:
AFAIK, there is one catch. We need to use va_copy() around
the 1st call because va_format can
On (20/09/24 10:54), Petr Mladek wrote:
> > Just a question:
> >
> > Can dynamic_textbuf be a PER_CPU array of five textbuf[1024] buffers
> > (for normal printk, nmi, hard irq, soft irq and one extra buffer for
> > recursive printk calls)?
>
> That would be my preferred fallback when the approach
On Thu 2020-09-24 15:17:46, Sergey Senozhatsky wrote:
> On (20/09/22 17:44), John Ogness wrote:
> > +/*
> > + * The sprint buffers are used with interrupts disabled, so each CPU
> > + * only requires 2 buffers: for non-NMI and NMI contexts. Recursive
> > + * printk() calls are handled by the safe b
On (20/09/24 10:45), Petr Mladek wrote:
> On Thu 2020-09-24 14:40:58, Sergey Senozhatsky wrote:
> > On (20/09/23 17:11), Petr Mladek wrote:
> > >
> > > AFAIK, there is one catch. We need to use va_copy() around
> > > the 1st call because va_format can be proceed only once.
> > >
> >
> > Current pr
On Thu 2020-09-24 14:40:58, Sergey Senozhatsky wrote:
> On (20/09/23 17:11), Petr Mladek wrote:
> >
> > AFAIK, there is one catch. We need to use va_copy() around
> > the 1st call because va_format can be proceed only once.
> >
>
> Current printk() should be good enough for reporting, say, "Kernel
On (20/09/22 17:44), John Ogness wrote:
> +/*
> + * The sprint buffers are used with interrupts disabled, so each CPU
> + * only requires 2 buffers: for non-NMI and NMI contexts. Recursive
> + * printk() calls are handled by the safe buffers.
> + */
> +#define SPRINT_CTX_DEPTH 2
> +
> +/* Static sp
On (20/09/23 17:11), Petr Mladek wrote:
>
> AFAIK, there is one catch. We need to use va_copy() around
> the 1st call because va_format can be proceed only once.
>
Current printk() should be good enough for reporting, say, "Kernel
stack overflow" errors. Is extra pressure that va_copy() adds somet
On (20/09/22 17:44), John Ogness wrote:
[..]
> int vprintk_store(int facility, int level,
> const struct dev_printk_info *dev_info,
> const char *fmt, va_list args)
> {
> - static char textbuf[LOG_LINE_MAX];
> - char *text = textbuf;
> size_t text_len
On Wed 2020-09-23 15:21:41, David Laight wrote:
> From: Petr Mladek
> > Sent: 23 September 2020 16:11
> >
> > On Tue 2020-09-22 17:44:14, John Ogness wrote:
> > > vprintk_store() is using a single static buffer as a temporary
> > > sprint buffer for the message text. This will not work once
> > >
From: Petr Mladek
> Sent: 23 September 2020 16:11
>
> On Tue 2020-09-22 17:44:14, John Ogness wrote:
> > vprintk_store() is using a single static buffer as a temporary
> > sprint buffer for the message text. This will not work once
> > @logbuf_lock is removed. Replace the single static buffer with
On Tue 2020-09-22 17:44:14, John Ogness wrote:
> vprintk_store() is using a single static buffer as a temporary
> sprint buffer for the message text. This will not work once
> @logbuf_lock is removed. Replace the single static buffer with a
> pool of buffers.
The buffer is used because we do not k
vprintk_store() is using a single static buffer as a temporary
sprint buffer for the message text. This will not work once
@logbuf_lock is removed. Replace the single static buffer with a
pool of buffers.
The pool is large enough to support a worse case of 2 contexts
per CPU (non-NMI and NMI).
Si
24 matches
Mail list logo
