Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp469944imm; Fri, 1 Jun 2018 04:21:45 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKgeM/t7DoD12qtaKP2v5+Pc9dS65XMZAP5ak4Jd16szq2D32PMXkhJyd3rOgoPKT9BVbCn X-Received: by 2002:a17:902:7048:: with SMTP id h8-v6mr3387445plt.269.1527852104965; Fri, 01 Jun 2018 04:21:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527852104; cv=none; d=google.com; s=arc-20160816; b=WiUPkJjMkY99GIOlYztHGQZ9LwL7Uzdpekjcvizaz9h1tvTXctsEA/pYDJY/6fGb02 oewt7EY2T8k7CmZTY1w7qcgFLDRX7OmOQ0Ir1r/FDWnC2W41Qr+HmCy1jJ+CyyxPOhdW Fxgk0i9e6fuFsFQR7ZTMnqbhGARrnyNrHHvzvv04zjOoxn+yTlkcZSQG7ThB4I7yIAXm t1ZScH30nwHy3DeGsZZRdbgB6oOkpRbm4pg8traVY9OW0IC/0Vt9IWpiDvizHyGnMQGm FxkG0ma1kToloOeHWHHANh6C2nM506CCe5Vu3UsiET6avKQ6vQy9sHmZfl6v/nF+JGZ+ 866g== 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:dmarc-filter:dkim-signature:dkim-signature :arc-authentication-results; bh=MKR3DwXt+Qy9womvx2IK5/p5VSnffUMrBjfnj7nbTOQ=; b=kH+mF/zNkbee7W2M6qEQWTqNNN/WZD0YJUmv2IUNcjim8bpaWaCANekd03+DwyaxMN VnZ4nv6H8iIzwQPRM/qD1OX8aXcIE7eCnATOquAat0B12gLYVKcNaxTy6nY1B3QqCk/c RGuHdY9uLecexywG82zKFKUDIcT3qqAo5VfHXL8wcQB5Vs7Ki/hvhgNxdtITtodlO8wd nLXMXvLxfzpIcYO69SBUCQYwQBGwfSDmSxRd5BN82Ot3XEnN+zVEwA5rpBj9FcEtfYaj ZYtaL8Y3McJYB9lGKIqMb9DOB01DwYyVSubayAyp2XOTkabP3qO76VfgogsCecC+hofk xTNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=UC+VoOBk; dkim=pass header.i=@codeaurora.org header.s=default header.b=Hlp3srgE; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u6-v6si39417786pld.74.2018.06.01.04.21.31; Fri, 01 Jun 2018 04:21:44 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b=UC+VoOBk; dkim=pass header.i=@codeaurora.org header.s=default header.b=Hlp3srgE; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751820AbeFALVB (ORCPT + 99 others); Fri, 1 Jun 2018 07:21:01 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:45766 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750790AbeFALU7 (ORCPT ); Fri, 1 Jun 2018 07:20:59 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id F123C606DD; Fri, 1 Jun 2018 11:20:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1527852059; bh=92r1bowWKxr97STq7w4t1FAQgTmN8O1BPet4Rif5MSI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UC+VoOBk2E6zBzEAa7dXKjQIrUAC5tvJogfy9WPgA1f4n9lOzBqkj1dcFUhqbo9tz nSsP7nlIXwF7j0Dh2YeJaVNprbrr+S5Uc2gvwgA/jc6MC+Kw5qsiOaY4MfE8Fm8XaT eqdwl668/9e2WYHGIbvfzyqTVtvUORxz5rRNluE4= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from codeaurora.org (blr-c-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: stummala@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id DCC6760261; Fri, 1 Jun 2018 11:20:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1527852058; bh=92r1bowWKxr97STq7w4t1FAQgTmN8O1BPet4Rif5MSI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Hlp3srgESChstDr+ROATO1JvXDYQcCC3njcP42C31mtoP6565gXczd3/xG4jArbm8 /rlLt9utjXK0822xZGHbA33HTvIHgZZ6w+EoU3euKn1LZzR/gaEjX3Jfvra6KhdloQ ijSmDB9IdU27mRcwi218mF6j9+c/SUmJL4HM5e7I= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org DCC6760261 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=stummala@codeaurora.org Date: Fri, 1 Jun 2018 16:50:50 +0530 From: Sahitya Tummala To: Michal Hocko 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: <20180601112050.GB12489@codeaurora.org> References: <20180601093235.GA12489@codeaurora.org> <20180601102609.GZ15278@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180601102609.GZ15278@dhcp22.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 01, 2018 at 12:26:09PM +0200, Michal Hocko wrote: > 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? > Let me correct my statement. It could be more of a livelock scenario. The direct reclaim path is not doing any writeback here, so the GFP_NOFS doesn't make any difference. In this case, the direct reclaim has to reclaim ~32 pages, which it picks up from the tail of the list. All of those tail pages are dirty and since direct reclaim path can't do any writeback, it just loops picking and skipping them. > > 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 -- -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.