Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp422251imm; Fri, 1 Jun 2018 03:26:57 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ4L+TjLSyXl1pOfkKq2Oq7OoPBdlhd18/eJ7nPmR5yk6uT0gsiXwLAIrX61xHKtEn5K6Dc X-Received: by 2002:a17:902:6546:: with SMTP id d6-v6mr10006760pln.196.1527848817255; Fri, 01 Jun 2018 03:26:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527848817; cv=none; d=google.com; s=arc-20160816; b=VPT9mq3VjPPoHJ895Mhy3k6zzNycBlgBd+b4DbCTaXlFwfm6gP63xPYw5i4J2uxyoZ xTlVyQs+fw9tc4voOcxyZe/+QLWJlUqqutLFWvO7bFXYi04nxyTnmrg+gyrIUz5FFS1N KgF5E9ObkVJWHjWLsOWO72a9AoOi4S83Gr5ne92UJxCJAQ1qV8uSCOfOogNTkWv2oHBW lhNeXXdRMZZbItCzTLIocBMDKdLrI4yJOLqJCkAngFGgZ42m1HjKx8fBlUe4SpzeZX6W WHEQx/877HgimgSOhfD1UFfW3V7tIrWNuymUAm48rPIVp0UgjWueEGzxR1AgFRO7cPgz mZbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=17ENv7fjMwc9JHwDZysWxBZ2fWfn05iKJPBxpzJqBMk=; b=wKgQDiOELPFBXUMXDmcu3yImvDv5chCrDd8DeGl2GHMKUJvj94WaO9DLDTe2SzkJrG GWNyhdhVPRNiXCjoI2495v9YyJE55oOT+NzyU28dBsIi7BwZu0mtya1UGbZNvKewXtqk yLysACy0ozcZAV/kYQGBkX8mj6YG7ftuohxpYNq6rl+lsvMfwlqtuaY8AgtTA+8J1Znt ZUuhcheHDQiSD2KuKRdOXDAziTJUR6Z1eu5pkd671q0NzMYzraYduZNe/+STyzzmDGVJ nianyaKXeAWC+pP7koOoeV3cLmxdHf4n3CQUieNjLMKvF2i2onDfCxrvjQhqpDpalzEJ taVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id be3-v6si38227301plb.474.2018.06.01.03.26.42; Fri, 01 Jun 2018 03:26:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751501AbeFAK0N (ORCPT + 99 others); Fri, 1 Jun 2018 06:26:13 -0400 Received: from mx2.suse.de ([195.135.220.15]:42851 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750793AbeFAK0L (ORCPT ); Fri, 1 Jun 2018 06:26:11 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 64961AE54; Fri, 1 Jun 2018 10:26:10 +0000 (UTC) Date: Fri, 1 Jun 2018 12:26:09 +0200 From: Michal Hocko To: Sahitya Tummala Cc: linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jaegeuk Kim , Chao Yu , vinmenon@codeaurora.org Subject: Re: deadlock during writeback when using f2fs filesystem Message-ID: <20180601102609.GZ15278@dhcp22.suse.cz> References: <20180601093235.GA12489@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180601093235.GA12489@codeaurora.org> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 01-06-18 15:02:35, Sahitya Tummala wrote: > Hi, > > We are observing a deadlock scenario during FS writeback under low-memory > condition with F2FS filesystem. > > Here is the callstack of this scenario - > > shrink_inactive_list() > shrink_node_memcg.isra.74() > shrink_node() > shrink_zones(inline) > do_try_to_free_pages(inline) > try_to_free_pages() > __perform_reclaim(inline) > __alloc_pages_direct_reclaim(inline) > __alloc_pages_slowpath(inline) > no_zone() > __alloc_pages(inline) > __alloc_pages_node(inline) > alloc_pages_node(inline) > __page_cache_alloc(inline) > pagecache_get_page() > find_or_create_page(inline) > grab_cache_page(inline) > f2fs_grab_cache_page(inline) > __get_node_page.part.32() > __get_node_page(inline) > get_node_page() > update_inode_page() > f2fs_write_inode() > write_inode(inline) > __writeback_single_inode() > writeback_sb_inodes() > __writeback_inodes_wb() > wb_writeback() > wb_do_writeback(inline) > wb_workfn() > > The writeback thread is entering into the direct reclaim path due to low-memory and is > getting stuck in shrink_inactive_list(), as shrink_inactive_list() is inturn waiting for > writeback to happen for the dirty pages present in the inactive list. shrink_page_list waits only for writeback pages when we are in the memcg reclaim. The above seems to be the global reclaim though. Moreover GFP_F2FS_ZERO is GFP_NOFS so we are not waiting for writeback pages at all. Are you sure the above is really a deadlock? > Do you think we can use GFP_NOWAIT for node mapping gfp_mask so that we can avoid direct > reclaim path in the writeback context? As we may now see allocation failures with this flag, > do you see any risk or issue in using it w.r.t F2FS FS and writeback? > Appreciate your suggestions on this. > > diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c > index 89c838b..d3daf3b 100644 > --- a/fs/f2fs/inode.c > +++ b/fs/f2fs/inode.c > @@ -316,7 +316,7 @@ struct inode *f2fs_iget(struct super_block *sb, unsigned long ino) > make_now: > if (ino == F2FS_NODE_INO(sbi)) { > inode->i_mapping->a_ops = &f2fs_node_aops; > - mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_ZERO); > + mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_NODE_MAPPING); > } else if (ino == F2FS_META_INO(sbi)) { > inode->i_mapping->a_ops = &f2fs_meta_aops; > mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_ZERO); > diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h > index 58aecb6..bb985cd 100644 > --- a/include/linux/f2fs_fs.h > +++ b/include/linux/f2fs_fs.h > @@ -47,6 +47,7 @@ > /* This flag is used by node and meta inodes, and by recovery */ > #define GFP_F2FS_ZERO (GFP_NOFS | __GFP_ZERO) > #define GFP_F2FS_HIGH_ZERO (GFP_NOFS | __GFP_ZERO | __GFP_HIGHMEM) > +#define GFP_F2FS_NODE_MAPPING (GFP_NOWAIT | __GFP_IO | __GFP_ZERO) > > Thanks, > Sahitya. > -- > -- > Sent by a consultant of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- Michal Hocko SUSE Labs