From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754257AbbJ0MHI (ORCPT ); Tue, 27 Oct 2015 08:07:08 -0400 Received: from mail-wi0-f176.google.com ([209.85.212.176]:35992 "EHLO mail-wi0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753639AbbJ0MHG (ORCPT ); Tue, 27 Oct 2015 08:07:06 -0400 Date: Tue, 27 Oct 2015 13:07:04 +0100 From: Michal Hocko To: Tejun Heo Cc: Tetsuo Handa , cl@linux.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, rientjes@google.com, oleg@redhat.com, kwalker@redhat.com, akpm@linux-foundation.org, hannes@cmpxchg.org, vdavydov@parallels.com, skozina@redhat.com, mgorman@suse.de, riel@redhat.com Subject: Re: [PATCH] mm,vmscan: Use accurate values for zone_reclaimable() checks Message-ID: <20151027120704.GF9891@dhcp22.suse.cz> References: <20151023083316.GB2410@dhcp22.suse.cz> <20151023103630.GA4170@mtj.duckdns.org> <20151023111145.GH2410@dhcp22.suse.cz> <201510232125.DAG82381.LMJtOQFOHVOSFF@I-love.SAKURA.ne.jp> <20151023182343.GB14610@mtj.duckdns.org> <201510251952.CEF04109.OSOtLFHFVFJMQO@I-love.SAKURA.ne.jp> <20151027092231.GC9891@dhcp22.suse.cz> <20151027105506.GB18741@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151027105506.GB18741@mtj.duckdns.org> 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 Tue 27-10-15 19:55:06, Tejun Heo wrote: > On Tue, Oct 27, 2015 at 10:22:31AM +0100, Michal Hocko wrote: > ... > > stable kernels without causing any other regressions. 2) is the way > > to move forward for next kernels and we should really think whether > > WQ_MEM_RECLAIM should imply also WQ_HIGHPRI by default. If there is a > > general consensus that there are legitimate WQ_MEM_RECLAIM users which > > can do without the other flag then I am perfectly OK to use it for > > vmstat and oom sysrq dedicated workqueues. > > I don't think flagging these things is a good approach. These are too > easy to miss. If this is a problem which needs to be solved, which > I'm not convined it is at this point, the right thing to do would be > doing stall detection and kicking the next work item automatically. To be honest, I do not really care whether this gets "fixed" in the stall detection code or by making WQ_MEM_RECLAIM to flag a special behavior implicitly. All I would like to see is to have a guarantee that such workqueues are not staying behind just because all current workers are in the allocator. Adding artificial schedule_timeouts in the allocator is a fragile way to work around the issue. -- Michal Hocko SUSE Labs