From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752318AbcCGIWO (ORCPT ); Mon, 7 Mar 2016 03:22:14 -0500 Received: from mx2.suse.de ([195.135.220.15]:60492 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752142AbcCGIWJ (ORCPT ); Mon, 7 Mar 2016 03:22:09 -0500 Date: Mon, 7 Mar 2016 09:22:30 +0100 From: Jan Kara To: Sergey Senozhatsky Cc: Tetsuo Handa , akpm@linux-foundation.org, jack@suse.com, pmladek@suse.com, tj@kernel.org, linux-kernel@vger.kernel.org, sergey.senozhatsky@gmail.com, jack@suse.cz Subject: Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async Message-ID: <20160307082230.GB5201@quack.suse.cz> References: <1457175338-1665-1-git-send-email-sergey.senozhatsky@gmail.com> <1457175338-1665-2-git-send-email-sergey.senozhatsky@gmail.com> <20160306063251.GA493@swordfish> <201603061618.GED43232.MtOQOFSLOFHJFV@I-love.SAKURA.ne.jp> <20160306093530.GA26055@swordfish> <201603062006.IJD17667.OOQFLtMVHOFSJF@I-love.SAKURA.ne.jp> <20160306132703.GA927@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160306132703.GA927@swordfish> 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 On Sun 06-03-16 22:27:03, Sergey Senozhatsky wrote: > On (03/06/16 20:06), Tetsuo Handa wrote: > [..] > > > do you mean a new worker allocation delay and a MAYDAY timer delay? > > > > > > > I don't know what MAYDAY is. I'm talking about a situation where printing_work > > work item is not processed (i.e. printing_work_func() is not called) until > > current work item calls schedule_timeout_*(). > > > > We had a problem that since vmstat_work work item was using system_wq, > > vmstat_work work item was not processed (i.e. vmstat_update() was not called) if > > kworker was looping inside memory allocator without calling schedule_timeout_*() > > due to disk_events_workfn() doing GFP_NOIO allocation). > > hm, just for note, none of system-wide wqs seem to have a ->rescuer thread > (WQ_MEM_RECLAIM). > > [..] > > Even if you use printk_wq with WQ_MEM_RECLAIM for printing_work work item, > > printing_work_func() will not be called until current work item calls > > schedule_timeout_*(). That will be an undesirable random delay. If you use > > a dedicated kernel thread rather than a dedicated workqueue with WQ_MEM_RECLAIM, > > we can avoid this random delay. > > hm. yes, seems that it may take some time until workqueue wakeup() a ->rescuer thread. > need to look more. Yes, it takes some time (0.1s or 2 jiffies) before workqueue code gives up creating a worker process and wakes up rescuer thread. However I don't see that as a problem... > > > console_lock(); > > > for (...) { > > > do_foo() { > > > ... > > > pr_err(" ... foo message ...\n"); > > > ... > > > } > > > } > > > console_unlock(); > > > > > > then yes, nothing will be printed until that process executes console_unlock(), > > > because it's console_unlock() that pushes the messages to console drivers. > > > > Yes, I meant a sequence like > > > > console_lock(); > > ptr = kmalloc(GFP_KERNEL); > > kfree(ptr); > > console_unlock(); > > > > and kmalloc() prints OOM killer messages rather than failing that allocation. > > Are we sure that there is no such usage? > > such usage is quite possible. > > problems that I have with console_lock()/console_unlock() is that > these functions serve a double purpose: exclusive printk() lock and a > console_drivers list lock. Well, but changing how console locking works is a separate issue, isn't it? So please as a separate patch set if you want to try it. Actually I don't think changing the locking will be so easy. console_lock/unlock is used e.g. for console blanking where you need to block any printing while you call ->unblank() for each console. That being said I don't think improvement is impossible, just given my experiences with console / printk code there will be surprises waiting for you :). Honza -- Jan Kara SUSE Labs, CR