From patchwork Fri Jun 1 09:32:35 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sahitya Tummala X-Patchwork-Id: 10442889 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2661E602BC for ; Fri, 1 Jun 2018 09:34:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 224C228F83 for ; Fri, 1 Jun 2018 09:34:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1707228F86; Fri, 1 Jun 2018 09:34:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 11DF928F83 for ; Fri, 1 Jun 2018 09:34:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751591AbeFAJcu (ORCPT ); Fri, 1 Jun 2018 05:32:50 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:38842 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751337AbeFAJcp (ORCPT ); Fri, 1 Jun 2018 05:32:45 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 5B4256021C; Fri, 1 Jun 2018 09:32:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1527845564; bh=2nbtJfeNq8Hbb6dNuwSx/YusXRqWClEtKWEdkRTqA7E=; h=Date:From:To:Cc:Subject:From; b=Raa7TPqe1VGJ7kDpKxTnqRjUydRFvcNvX27DXp4W9jLl6TB5AH7Ox1t2diiutVjmm HseyAdSX6HmC8jWAullIPAlD6P7VUvPyMc5ZTf873o3RGEsD4b6FVoILjUqO1hZrKf uDLC0SrFX5VHAR5wfdTP/XcQ63fa9AcA4swx4MWs= 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 3C0FF6021C; Fri, 1 Jun 2018 09:32:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1527845563; bh=2nbtJfeNq8Hbb6dNuwSx/YusXRqWClEtKWEdkRTqA7E=; h=Date:From:To:Cc:Subject:From; b=CymYMEPijKYtoCpGRB+cV8SnO2uw7Goc6r5Ne7+4cYmnpKnO+L5LgK9sDWxrTloJU nDKxRk4CiUNVCspWNiC4uCMmKm62LKYcxM+opbR2HuB2T8CYn2xYIethL/TQBoAvhj pMgsNsvM06k+Is6OFIIzJj3vpnJjIeHtqHEEyE4c= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 3C0FF6021C 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 15:02:35 +0530 From: Sahitya Tummala To: linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jaegeuk Kim , Chao Yu Cc: vinmenon@codeaurora.org, stummala@codeaurora.org Subject: deadlock during writeback when using f2fs filesystem Message-ID: <20180601093235.GA12489@codeaurora.org> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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. 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.