From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753186AbcCGPmk (ORCPT ); Mon, 7 Mar 2016 10:42:40 -0500 Received: from mail-yw0-f195.google.com ([209.85.161.195]:33011 "EHLO mail-yw0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753132AbcCGPma (ORCPT ); Mon, 7 Mar 2016 10:42:30 -0500 Date: Mon, 7 Mar 2016 10:42:27 -0500 From: Tejun Heo To: Jan Kara Cc: Sergey Senozhatsky , Tetsuo Handa , akpm@linux-foundation.org, jack@suse.com, pmladek@suse.com, linux-kernel@vger.kernel.org, sergey.senozhatsky@gmail.com Subject: Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async Message-ID: <20160307154227.GA7065@htj.duckdns.org> 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> <20160307082230.GB5201@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160307082230.GB5201@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, On Mon, Mar 07, 2016 at 09:22:30AM +0100, Jan Kara wrote: > > > 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_*(). That was because the work item was percpu and not marked CPU_INTENSIVE. Either using an unbound or CPU_INTENSIVE workqueue should be enough. > > > 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). Because WQ_MEM_RECLAIM only guarantees concurrency of 1, it doesn't make sense to set it to a shared workqueue. A dedicated workquee should be created per domain which needs forward progress guarantee. > > 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... I don't think it matters. At that point, the system should already be thrashing heavily and everything is crawling anyway. A couple jiffies delay isn't gonna be noticeable. Thanks. -- tejun