From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753863AbbJ0KzR (ORCPT ); Tue, 27 Oct 2015 06:55:17 -0400 Received: from mail-pa0-f46.google.com ([209.85.220.46]:36160 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753273AbbJ0KzP (ORCPT ); Tue, 27 Oct 2015 06:55:15 -0400 Date: Tue, 27 Oct 2015 19:55:06 +0900 From: Tejun Heo To: Michal Hocko 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: <20151027105506.GB18741@mtj.duckdns.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151027092231.GC9891@dhcp22.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 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. Thanks. -- tejun