[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3d6c42b0734a4713b45647415a51bcc1@AcuMS.aculab.com>
Date: Wed, 30 Sep 2020 14:32:12 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Steven Rostedt' <rostedt@...dmis.org>,
Rasmus Villemoes <rasmus.villemoes@...vas.dk>
CC: Petr Mladek <pmladek@...e.com>,
John Ogness <john.ogness@...utronix.de>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH printk 3/5] printk: use buffer pool for sprint buffers
From: Steven Rostedt
> Sent: 30 September 2020 14:36
>
> On Wed, 30 Sep 2020 10:06:24 +0200
> Rasmus Villemoes <rasmus.villemoes@...vas.dk> 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 unconditionally doing vsnprintf() twice is a bad
> > idea.
>
> But the console output is usually magnitudes more expensive than the
> vsnprintf(), would doing it twice really make a difference?
Are there any strange %pX modifiers that do anything really horrid?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists