Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754104AbbLCU4i (ORCPT ); Thu, 3 Dec 2015 15:56:38 -0500 Received: from mail-yk0-f176.google.com ([209.85.160.176]:35250 "EHLO mail-yk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754224AbbLCU4f (ORCPT ); Thu, 3 Dec 2015 15:56:35 -0500 Date: Thu, 3 Dec 2015 15:56:32 -0500 From: Tejun Heo To: Peter Zijlstra Cc: Ulrich Obergfell , Ingo Molnar , Andrew Morton , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH] workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue Message-ID: <20151203205632.GM27463@mtj.duckdns.org> References: <20151203002810.GJ19878@mtj.duckdns.org> <20151203093350.GP17308@twins.programming.kicks-ass.net> <20151203100018.GO11639@twins.programming.kicks-ass.net> <20151203144811.GA27463@mtj.duckdns.org> <20151203150442.GR17308@twins.programming.kicks-ass.net> <20151203150604.GC27463@mtj.duckdns.org> <20151203192616.GJ27463@mtj.duckdns.org> <20151203204313.GX17308@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151203204313.GX17308@twins.programming.kicks-ass.net> 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 Content-Length: 1846 Lines: 41 Hey, Peter. On Thu, Dec 03, 2015 at 09:43:13PM +0100, Peter Zijlstra wrote: > I'm not sure about using PF_MEMALLOC for detecting reclaim. There appear > to be more sites setting this than reclaim. See: > > drivers/block/nbd.c: current->flags |= PF_MEMALLOC; > drivers/mmc/card/queue.c: current->flags |= PF_MEMALLOC; > drivers/mtd/nand/nandsim.c: current->flags |= PF_MEMALLOC; > drivers/scsi/iscsi_tcp.c: current->flags |= PF_MEMALLOC; > drivers/staging/lustre/include/linux/libcfs/linux/linux-mem.h:#define memory_pressure_set() do { current->flags |= PF_MEMALLOC; } while (0) > fs/cifs/connect.c: current->flags |= PF_MEMALLOC; > fs/xfs/libxfs/xfs_btree.c: new_pflags |= PF_MEMALLOC | PF_SWAPWRITE | PF_KSWAPD; > fs/xfs/xfs_trans_ail.c: current->flags |= PF_MEMALLOC; > include/linux/sched.h: current->flags |= PF_MEMALLOC_NOIO; > mm/page_alloc.c: current->flags |= PF_MEMALLOC; > mm/page_alloc.c: current->flags |= PF_MEMALLOC; > mm/vmscan.c: tsk->flags |= PF_MEMALLOC | PF_SWAPWRITE | PF_KSWAPD; > mm/vmscan.c: p->flags |= PF_MEMALLOC; > mm/vmscan.c: p->flags |= PF_MEMALLOC | PF_SWAPWRITE; > net/core/dev.c: current->flags |= PF_MEMALLOC; > net/core/sock.c: current->flags |= PF_MEMALLOC; > > > The actual reclaim sites in page_alloc and vmscan set > current->reclaim_state. So testing against that might be more accurate. So, if I'm not mistaken, those are all marking tasks which can be depended upon during memory reclaim and we do want to catch them all. PF_MEMALLOC shouldn't depend on something which require memory to be reclaimed to guarantee forward progress. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/