Re: [PATCH] printk: introduce should_ignore_loglevel()

2016-06-27 Thread Sergey Senozhatsky
On (06/27/16 11:26), Petr Mladek wrote: > On Sat 2016-06-25 14:22:37, Sergey Senozhatsky wrote: > > On (06/24/16 18:05), Petr Mladek wrote: > > [..] > > > > +static bool should_ignore_loglevel(int level) > > > > +{ > > > > + return (level >= console_loglevel && !ignore_loglevel); > > > > > >

Re: [PATCH] printk: introduce should_ignore_loglevel()

2016-06-27 Thread Petr Mladek
On Sat 2016-06-25 14:22:37, Sergey Senozhatsky wrote: > On (06/24/16 18:05), Petr Mladek wrote: > [..] > > > +static bool should_ignore_loglevel(int level) > > > +{ > > > + return (level >= console_loglevel && !ignore_loglevel); > > > > The patch looks fine. It is nice optimization. > > > > I was

Re: [PATCH] printk: introduce should_ignore_loglevel()

2016-06-24 Thread Sergey Senozhatsky
On (06/24/16 18:05), Petr Mladek wrote: [..] > > +static bool should_ignore_loglevel(int level) > > +{ > > + return (level >= console_loglevel && !ignore_loglevel); > > The patch looks fine. It is nice optimization. > > I was just quite confused by the name of this function. A function > called

Re: [PATCH] printk: introduce should_ignore_loglevel()

2016-06-24 Thread Petr Mladek
On Fri 2016-06-24 01:33:02, Sergey Senozhatsky wrote: > The thing here is this deferred `level >= console_loglevel' check. We are > wasting CPU cycles on sprintfs/memcpy/etc. preparing the messages that we > will eventually drop. > > Signed-off-by: Sergey Senozhatsky > --- > kernel/printk/printk

[PATCH] printk: introduce should_ignore_loglevel()

2016-06-23 Thread Sergey Senozhatsky
Due to deferred printing, console log level is inspected when the actual printing occurs, which may provoke console_unlock() and console_cont_flush() to waste CPU cycles on every message that has loglevel above the current console_loglevel. Schematically, console_unlock() does the following: cons