From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932856AbcAKN1a (ORCPT ); Mon, 11 Jan 2016 08:27:30 -0500 Received: from mail-pf0-f193.google.com ([209.85.192.193]:36144 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751323AbcAKN11 (ORCPT ); Mon, 11 Jan 2016 08:27:27 -0500 Date: Mon, 11 Jan 2016 22:25:44 +0900 From: Sergey Senozhatsky To: Jan Kara Cc: Sergey Senozhatsky , Sergey Senozhatsky , Andrew Morton , Petr Mladek , KY Sri nivasan , Steven Rostedt , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/7] printk: Hand over printing to console if printing too long Message-ID: <20160111132544.GA579@swordfish> References: <20151210145251.GA540@swordfish> <20151222134730.GD7266@quack.suse.cz> <20151223015420.GA2008@swordfish> <20160105143717.GC14464@quack.suse.cz> <20160106064836.GC781@swordfish> <20160106122517.GC24046@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160106122517.GC24046@quack.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Jan, On (01/06/16 13:25), Jan Kara wrote: [..] > > a quote from -mm a74b6533ead8 http://www.spinics.net/lists/linux-mm/msg98990.html [..] > > particularly this "workqueue context is not appropriate because all the workers > > might be busy (e.g. allocating memory)" part. I think printk should switch to > > sync mode in this case, since printk now does queue_work(system_wq, work). > > um... console_verbose() call from oom kill? but it'll be nice to return back > > to async mode once (if) memory pressure goes away. > > Hum, yes, some mechanism to switch to sync printing in case work cannot be > executed for a long time is probably needed. I'll think about it. well, technically, worker_pool keeps ->watchdog_ts updated, so ,basically, worker pool knows when it stall. with CONFIG_WQ_WATCHDOG enabled timer_fn wq_watchdog_timer_fn() checks that value and pr_emerg(). in the worst case, printk can depend on CONFIG_WQ_WATCHDOG (yes, this sounds a bit sad) -- which implies, however, potentially long print from timer_fn. having a printk() specific timer_fn, that will do the same, is just a duplication of functionality; and checking the value in every vprintk_emit() is not really an option too, I'm afraid, there may be no printk calls for some time. just my 5 cents. probably you have better ideas. one another thing, include/linux/workqueue.h says : System-wide workqueues which are always present. : : system_wq is the one used by schedule[_delayed]_work[_on](). : Multi-CPU multi-threaded. There are users which expect relatively : short queue flush time. Don't queue works which can run for too : long. : [..] : : system_long_wq is similar to system_wq but may host long running : works. Queue flushing might take relatively long. : : system_unbound_wq is unbound workqueue. Workers are not bound to : any specific CPU, not concurrency managed, and all queued works are : executed immediately as long as max_active limit is not reached and : resources are available. wake_up_klogd_work_func() is using `system_wq' to do 'console_lock()/console_unlock()', both of which can take a long time. should it be switched to `system_long_wq' or `system_unbound_wq'? -ss