From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D886ECAC5BB for ; Thu, 9 Oct 2025 02:25:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Type:Content-Transfer-Encoding:Cc: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:In-Reply-To:References:To:MIME-Version:Date: Message-ID:Sender:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=NwYyTyafwWDWrGeLxa+xRojqr/N6Gl0cSBwRmS0/YPs=; b=CrIq25qgAZMhdJdjXPwSFJT0/I Zs+qsWnte+zDx5oKEljmcFNARTG8NznUIk6is9CZzutsLD8WelzmzlLW7WpyZtGte2sTxQ68S3sF6 8tVjQoiadfhUnn9AGaTuGMImMqWaIlFZDPedJyeHxxqT+GOZhy9r7ntmQMgb6UespTUQ=; Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1v6gLa-0000rI-Qc; Thu, 09 Oct 2025 02:25:39 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1v6gLZ-0000r2-Dk for linux-f2fs-devel@lists.sourceforge.net; Thu, 09 Oct 2025 02:25:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:To:Subject:Cc:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=2YzXUDoVv4IVAWqVpcRvdLzDjB49JEso9+2HfFDZ9Vw=; b=au/LSgPuRuquYyrKxlvPl8azPu LBi38cZDKXQR3jJQm09RzCVsflbWwfSUYSCW9lxmK7bHwqH0UJVQ2zihCtt0IP38OIJ4GVHT4NER0 xfN7ifidip+GJmgeNNS00d9U6D+FYq4AlpfElKWNv7yvqUeW0sr55Wv7O6UtCVQTlUJ4=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:To: Subject:Cc:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2YzXUDoVv4IVAWqVpcRvdLzDjB49JEso9+2HfFDZ9Vw=; b=Frfk7gIXim7N0yl7Vsa5Ed3gLt R15aXp+7ZE0D1KN8BjP9PNPgfVtioeKhF2XqtBNWPQ/nn/Cyj7WkE6MKY5HGZvqOGzFeiXXK/tdRL 12VrvxbIfTOp/8OeZMcGDNPOrcX8NvOnHAxdfMLgY4XNslt0ib4vQIen/ZpgTC7In/Ls=; Received: from sea.source.kernel.org ([172.234.252.31]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1v6gLZ-0003ZO-Gs for linux-f2fs-devel@lists.sourceforge.net; Thu, 09 Oct 2025 02:25:38 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 332DC40B9B; Thu, 9 Oct 2025 02:25:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86F00C4CEE7; Thu, 9 Oct 2025 02:25:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759976727; bh=vTHUzqFcW/mNj3h30ZYRTuoryqWPNMypz+oxpm5+J2Q=; h=Date:Cc:Subject:To:References:From:In-Reply-To:From; b=kUoRsDNyMTjv+cj67esksGIfpPFtp8srOdqrWxjZ5l6L7YaZXT+id9VcnpoLtemfD FApDJAT7tfoGXMhZV0A3zqqorfAOwR00zWkWOhpZ6n9DMRH8eCmmivOQbhu/cjAMpi 5rE2Q5d03+rBQe2uieLD6OvzINzZuLxArJlIn1xYosiWHXSLp5qpBdG5NHd06lSADr yGYeAn53AGJYq/EEs+FUMCU48OuINKPnthnBzhiVNC5DTsiKgi8SjWq0MDbAOgKux3 XULbTH8cMV/s6F37Gfp6FvpUABdTR0gNY5EU3AeZT7iSVaCpxb46uXPZKNvNmfifd4 bpBRWYdyEc/XA== Message-ID: <849959ea-b86e-400c-a33f-d1d6b1745267@kernel.org> Date: Thu, 9 Oct 2025 10:25:27 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Jiucheng Xu , Jaegeuk Kim References: <20250918-origin-dev-v1-1-8d9877df9e77@amlogic.com> Content-Language: en-US In-Reply-To: X-Headers-End: 1v6gLZ-0003ZO-Gs Subject: Re: [f2fs-dev] [PATCH] f2fs: Use mapping->gfp_mask to get file cache for writing X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Chao Yu via Linux-f2fs-devel Reply-To: Chao Yu Cc: tuan.zhang@amlogic.com, linux-kernel@vger.kernel.org, jianxin.pan@amlogic.com, linux-f2fs-devel@lists.sourceforge.net Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On 9/30/2025 11:17 AM, Jiucheng Xu wrote: > > > On 9/24/2025 10:25 AM, Chao Yu wrote: >> [ EXTERNAL EMAIL ] >> >> On 9/18/25 11:32, Jiucheng Xu via B4 Relay wrote: >>> From: Jiucheng Xu >>> >>> On 32-bit architectures, when GFP_NOFS is used, the file cache for write >>> operations cannot be allocated from the highmem and CMA. >> >> Hi, >> >> Have you suffered any problem w/o this patch? Can you please describe more >> details about it? >> > Hi Chao, > > Thanks for your comments. > > Our a platform uses a 1.5G DRAM, and the kernel is aarch32. > We have a critical scenario where system need to record multimedia data > while replaying the previously recorded multimedia files. However, > stuttering often occurs during playback. The problem does not arise on > aarch64 platforms with the same memory size. > > We have analyzed the root cause as follows: > Data written using GFP_NOFS is only allocated from normal memory. Since > the normal memory is only 768MB, it easily triggers the kswapd to > reclaim memory, which in turn reclaims and clears the file cache of the > recorded data. As a result, during playback, the system fails to hit the > file cache and thus has to re-read data directly from the storage. Given > that our storage has relatively poor performance, concurrent read > (playback) and write (recording) operations lead to significant IO > latency. High read latency then causes stuttering during playback. Hi Jiucheng, Thanks for the explanation. >>> >>> Since mapping->gfp_mask is set to GFP_HIGHUSER_MOVABLE during inode >> >> GFP_HIGHUSER_MOVABLE includes __GFP_FS, we should avoid using __GFP_FS here. >> f2fs_write_begin() uses GFP_NOFS like the most of other filesystem to avoid >> potential deadlock, as __filemap_get_folio(, .. |__GFP_FS | ..) may run into >> memory reclaim to call ->writeback in where we may suffer deadlock potentially. >> > Since our platform only support 5.15 kernel, I have checked > EXT4/FAT/ntfs3 and find they all use mapping_gfp_mask(mapping)) as GFP Yes, but also we can see iomap gets rid of using __GFP_FS by default: struct folio *iomap_get_folio(struct iomap_iter *iter, loff_t pos, size_t len) { fgf_t fgp = FGP_WRITEBEGIN | FGP_NOFS; if (iter->flags & IOMAP_NOWAIT) fgp |= FGP_NOWAIT; if (iter->flags & IOMAP_DONTCACHE) fgp |= FGP_DONTCACHE; fgp |= fgf_set_order(len); return __filemap_get_folio(iter->inode->i_mapping, pos >> PAGE_SHIFT, fgp, mapping_gfp_mask(iter->inode->i_mapping)); } > flag to get page cache on kernel 5.15: > > 6100cca: > ___GFP_HIGHMEM |___GFP_MOVABLE | ___GFP_IO | ___GFP_FS > |___GFP_DIRECT_RECLAIM |___GFP_KSWAPD_RECLAIM |___GFP_HARDWALL > |___GFP_SKIP_KASAN_UNPOISON | ___GFP_SKIP_KASAN_POISON > > therefor that's why I recommend this flag. > > I'm not sure if the above flags has some problems on f2fs, so I submit > it and would be very eager to learn about the views of your experts. IIRC, f2fs uses GFP_NOFS in ->write_begin for long time w/o any problem, in order to avoid any potential issue by using ___GFP_FS, and also to consider allowing memory allocation w/ ___GFP_HIGHMEM & ___GFP_MOVABLE, what about changing as below: folio = __filemap_get_folio(mapping, index, FGP_LOCK | FGP_WRITE | FGP_CREAT | FGP_NOFS, mapping_gfp_mask(mapping)); Thanks, > > Thanks and Best Regards, > Jiucheng > >> Thanks, >> >>> allocation, using mapping_gfp_mask(mapping) as the GFP flag of getting file >>> cache for writing is more efficient for 32-bit architectures. >>>> Signed-off-by: Jiucheng Xu >>> --- >>> fs/f2fs/data.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c >>> index 7961e0ddfca3aaa332b7dbd4985ae7766551834f..9fbc41f9accb2626da22754f1a424da4805ca823 100644 >>> --- a/fs/f2fs/data.c >>> +++ b/fs/f2fs/data.c >>> @@ -3587,7 +3587,8 @@ static int f2fs_write_begin(const struct kiocb *iocb, >>> * Will wait that below with our IO control. >>> */ >>> folio = __filemap_get_folio(mapping, index, >>> - FGP_LOCK | FGP_WRITE | FGP_CREAT, GFP_NOFS); >>> + FGP_LOCK | FGP_WRITE | FGP_CREAT, >>> + mapping_gfp_mask(mapping)); >>> if (IS_ERR(folio)) { >>> err = PTR_ERR(folio); >>> goto fail; >>> >>> --- >>> base-commit: c872b6279cd26762339ff02513e2a3f16149a6f1 >>> change-id: 20250910-origin-dev-8a5ff6bee1f2 >>> >>> Best regards, >> > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel