From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751860AbdGDF0F (ORCPT <rfc822;w@1wt.eu>);
        Tue, 4 Jul 2017 01:26:05 -0400
Received: from mail-pg0-f68.google.com ([74.125.83.68]:36787 "EHLO
        mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750798AbdGDF0E (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 4 Jul 2017 01:26:04 -0400
Date: Tue, 4 Jul 2017 14:26:06 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Jan Kara <jack@suse.cz>, Andrew Morton <akpm@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        "Rafael J . Wysocki" <rjw@rjwysocki.net>,
        Eric Biederman <ebiederm@xmission.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jslaby@suse.com>, Pavel Machek <pavel@ucw.cz>,
        Andreas Mohr <andi@lisas.de>,
        Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread
Message-ID: <20170704052606.GC3013@jagdpanzerIV.localdomain>
References: <20170510055935.GA1966@jagdpanzerIV.localdomain>
 <20170529092906.GD21894@pathway.suse.cz>
 <20170531072233.GC7672@jagdpanzerIV.localdomain>
 <20170628121925.GN1538@pathway.suse.cz>
 <20170629073321.GA475@jagdpanzerIV.localdomain>
 <20170630070131.GA474@jagdpanzerIV.localdomain>
 <20170630131610.GT1538@pathway.suse.cz>
 <20170630133844.GD792@jagdpanzerIV.localdomain>
 <20170703111130.GA836@jagdpanzerIV.localdomain>
 <20170703153414.65ab12e3@gandalf.local.home>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170703153414.65ab12e3@gandalf.local.home>
User-Agent: Mutt/1.8.3 (2017-05-23)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On (07/03/17 15:34), Steven Rostedt wrote:
> > +#define PRINTK_FLOOD_DEFAULT_DELAY	10
> > +
> >  int printk_delay_msec __read_mostly;
> >  
> > +static inline void __printk_delay(int m)
> > +{
> > +	while (m--) {
> > +		mdelay(1);
> > +		touch_nmi_watchdog();
> > +	}
> > +}
> > +
> >  static inline void printk_delay(void)
> >  {
> > -	if (unlikely(printk_delay_msec)) {
> > -		int m = printk_delay_msec;
> > +	unsigned long flags;
> > +	u64 console_seen = 0, console_to_see;
> >  
> > -		while (m--) {
> > -			mdelay(1);
> > -			touch_nmi_watchdog();
> > -		}
> > +	if (printk_delay_msec) {
> > +		__printk_delay(printk_delay_msec);
> > +		return;
> > +	}
> > +
> 
> This had better be an option, and not default.

yes.

> And what happens if the printk caller happens to preempt the one
> doing the writes to consoles?

in short - we just burn CPU cycles. that case is broken.

that's mostly the reason behind PRINTK_FLOOD_DEFAULT_DELAY being quite
small.

one can simply do

	console_lock();
	printk();
	printk();
	....
	printk();
	console_unlock();

and trigger a useless throttling. a needed one in general case,
but useless in the given circumstances.

not sure if we can properly throttle printk in all of the cases.
we know that console_sem is locked, but we don't know what for.
is CPU that owns the console_sem is now in console_unlock() or
somewhere in fbcon, or anywhere else. we probably need not to
throttle printk() if we know that console_sem is already locked
by this_cpu and we simply call printk either from IRQ that
preempted console_unlock() on this_cpu or recursive printk from
console_unlock()... and so on.

	-ss