From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f52.google.com ([209.85.220.52]:33519 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752465AbbLDA2p (ORCPT ); Thu, 3 Dec 2015 19:28:45 -0500 Date: Fri, 4 Dec 2015 09:29:45 +0900 From: Sergey Senozhatsky To: Jan Kara Cc: Sergey Senozhatsky , tj@kernel.org, akpm@linux-foundation.org, calvinowens@fb.com, davej@codemonkey.org.uk, jack@suse.com, kyle@kernel.org, stable@vger.kernel.org, mm-commits@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: + printk-do-cond_resched-between-lines-while-outputting-to-consoles.patch added to -mm tree Message-ID: <20151204002945.GA3313@swordfish> References: <565f855a./bN6NB3bZKjpF4Wa%akpm@linux-foundation.org> <20151203011129.GA510@swordfish> <20151203023932.GB510@swordfish> <20151203095739.GA21988@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151203095739.GA21988@quack.suse.cz> Sender: stable-owner@vger.kernel.org List-ID: On (12/03/15 10:57), Jan Kara wrote: [..] > > > CPU2 still can cause lots of troubles. consider > > > > > > CPU0 CPU1 CPU2 > > > printk > > > ... printk_deferred > > > printk wake_up_klogd > > > wake_up_klogd_work_func > > > console_trylock > > > console_unlock > > > > > > printk_deferred() may be issued by scheduler, for example. > > > > IOW, may be we can start limiting the number of bytes printed in console_unlock() > > from irq contexts. Which is quite ugly, yes. We basically don't know how much time > > we spend in call_console_drivers(); some of the consoles can do 'internal' spin_lock > > loops in ->write() handlers, etc. So something like this (below) probably will not > > really help, but still it's not always OK to do `while (1)' loop in console_unlock() > > for irqs. > > What we really want is pushing the printing into async context (unless > forced by debug option or oops in progress). Because what you do here fixes > only a small fraction of the problem space. I have patches which fix more > of it (https://lkml.org/lkml/2015/10/26/16) but they are still not enough > because on large machines e.g. udev times out because printing messages > about inserted hardware over serial console just takes too long. absolutely agree. thanks for the link! -ss