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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06951C4708D for ; Wed, 7 Dec 2022 20:51:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 84C418E0003; Wed, 7 Dec 2022 15:51:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7FCD18E0001; Wed, 7 Dec 2022 15:51:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C5B98E0003; Wed, 7 Dec 2022 15:51:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5F3768E0001 for ; Wed, 7 Dec 2022 15:51:30 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 12F53C0CA1 for ; Wed, 7 Dec 2022 20:51:30 +0000 (UTC) X-FDA: 80216705940.06.2716A79 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf10.hostedemail.com (Postfix) with ESMTP id D9F99C0003 for ; Wed, 7 Dec 2022 20:51:26 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=HB0cbnty; spf=none (imf10.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670446288; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UORhhcQqOaIvpRwHi0DMFterbhwvG2EXcBZ82YBwQMU=; b=1KoWPuAwrwbs1vSySZLilGL8f04rPjkvgJkOs6bRLYrdj7orQjwNbcPy83WNOVfQocjvbc VfZP/xF6tl2x/L7EqJDDjs/cHaL3gig/Ck1o3icBqtZr3TDzE8qVG2vQpaRjH+yJ9Eh2+9 jeTO8xrZJbEruZqPCjTX0+cNEkC+HrI= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=HB0cbnty; spf=none (imf10.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670446288; a=rsa-sha256; cv=none; b=uOmqbXJOiRbZHj/cIVt4OeaJ3N2O8tZmprDkGLpQMjH/FA6uao/FWEzEYiREHkyt7KWgPi BeR4epljmO15uth7ETs3xZ2PW1w5jtTMdnrwPdOYvrqkVXilq2Jm8o/vNx82+mbB7fZQd7 fltmQSjVwFo8w0MULrC3QnYe7Oe8mUM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=UORhhcQqOaIvpRwHi0DMFterbhwvG2EXcBZ82YBwQMU=; b=HB0cbntyJzwuDFdxDCnp+Vlwhk tSONA7EaFAT9b+ZkRhi8SCpbuaWYeyV5dX92dXFFQy0XLTwjZ8b+qZwY47nxK7r2JS3AhDY/Y2q18 YQWeVOWuZLc56HAj71ksdMyTmxK6OQToCGUwu1P6WxiBWym+wp+/POSm1HgoJ8F5etqzNTjvaY9bB oumvoTFfM93KB+IZtwPw2qExrWTiQawM9qjY/9m+jEcmlrXCaa4To5UgSUoi6LVA0YsHiwMLJcwMm Txs6DUb29cPIuy/ivStLtb5yUJUpwXE8cCLBgzfJaZSs2U6XAo+6S6gBoGM5zgOeszjBtmgcza8E+ ms0w9KNw==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1p31Np-00CLcf-VD; Wed, 07 Dec 2022 20:51:14 +0000 Date: Wed, 7 Dec 2022 12:51:13 -0800 From: Luis Chamberlain To: Matthew Wilcox , Pankaj Raghav , Jaegeuk Kim Cc: Yangtao Li , chao@kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, fengnanchang@gmail.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, vishal.moola@gmail.com, Javier =?iso-8859-1?Q?Gonz=E1lez?= , Adam Manzanares Subject: Re: [PATCH] f2fs: Support enhanced hot/cold data separation for f2fs Message-ID: References: <20221130124804.79845-1-frank.li@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: D9F99C0003 X-Stat-Signature: 7tqqpeca7nk3ktiiu8qpw8rn6ayhkh83 X-Rspam-User: X-Spamd-Result: default: False [-4.30 / 9.00]; BAYES_HAM(-6.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; FORGED_SENDER(0.30)[mcgrof@kernel.org,mcgrof@infradead.org]; R_DKIM_ALLOW(-0.20)[infradead.org:s=bombadil.20210309]; RCVD_NO_TLS_LAST(0.10)[]; DMARC_POLICY_SOFTFAIL(0.10)[kernel.org : No valid SPF, DKIM not aligned (relaxed),none]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[mcgrof@kernel.org,mcgrof@infradead.org]; RCVD_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; DKIM_TRACE(0.00)[infradead.org:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWELVE(0.00)[13]; TO_DN_SOME(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; TAGGED_RCPT(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Server: rspam08 X-HE-Tag: 1670446286-469366 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000060, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Nov 30, 2022 at 03:18:41PM +0000, Matthew Wilcox wrote: > On Wed, Nov 30, 2022 at 08:48:04PM +0800, Yangtao Li wrote: > > Hi, > > > > > Thanks for reviewing this. I think the real solution to this is > > > that f2fs should be using large folios. That way, the page cache > > > will keep track of dirtiness on a per-folio basis, and if your folios > > > are at least as large as your cluster size, you won't need to do the > > > f2fs_prepare_compress_overwrite() dance. And you'll get at least fifteen > > > dirty folios per call instead of fifteen dirty pages, so your costs will > > > be much lower. > > > > > > Is anyone interested in doing the work to convert f2fs to support > > > large folios? I can help, or you can look at the work done for XFS, > > > AFS and a few other filesystems. > > > > Seems like an interesting job. Not sure if I can be of any help. > > What needs to be done currently to support large folio? > > > > Are there any roadmaps and reference documents. > > >From a filesystem point of view, you need to ensure that you handle folios > larger than PAGE_SIZE correctly. The easiest way is to spread the use > of folios throughout the filesystem. For example, today the first thing > we do in f2fs_read_data_folio() is convert the folio back into a page. > That works because f2fs hasn't told the kernel that it supports large > folios, so the VFS won't create large folios for it. > > It's a lot of subtle things. Here's an obvious one: > zero_user_segment(page, 0, PAGE_SIZE); > There's a folio equivalent that will zero an entire folio. > > But then there is code which assumes the number of blocks per page (maybe > not in f2fs?) and so on. Every filesystem will have its own challenges. > > One way to approach this is to just enable large folios (see commit > 6795801366da or 8549a26308f9) and see what breaks when you run xfstests > over it. Probably quite a lot! Me and Pankaj are very interested in helping on this front. And so we'll start to organize and talk every week about this to see what is missing. First order of business however will be testing so we'll have to establish a public baseline to ensure we don't regress. For this we intend on using kdevops so that'll be done first. If folks have patches they want to test in consideration for folio / iomap enhancements feel free to Cc us :) After we establish a baseline we can move forward with taking on tasks which will help with this conversion. [0] https://github.com/linux-kdevops/kdevops Luis