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 5FFD7D59F7C for ; Wed, 6 Nov 2024 23:56:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C314F6B0092; Wed, 6 Nov 2024 18:56:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BE05E6B0098; Wed, 6 Nov 2024 18:56:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA80E6B0099; Wed, 6 Nov 2024 18:56:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8CC946B0092 for ; Wed, 6 Nov 2024 18:56:29 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3CF65AB200 for ; Wed, 6 Nov 2024 23:56:29 +0000 (UTC) X-FDA: 82757330754.25.B873314 Received: from out-179.mta1.migadu.com (out-179.mta1.migadu.com [95.215.58.179]) by imf12.hostedemail.com (Postfix) with ESMTP id 79B224001B for ; Wed, 6 Nov 2024 23:56:11 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=gXs7qhov; spf=pass (imf12.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.179 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730937163; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WwjeiWb2K0qdNecBV8zVccaOFulKNeLja/T2sJGrqx8=; b=xb8r+E72g63T0mxzM5pARjTYqvAfrWwQHwDg6wNZ/w8qOaOnBRffR7Jws1fIfgiAzB9E1B 9gJKsnXbuxtfluBwHJbuExUSCz+nfsPT6ForYDjZVaYO+Y8CDDMCzNeZJ0IaleMkbsV7n5 bvxBpLFzBGK0UHOGw5PdDc3OtFeu4DQ= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=gXs7qhov; spf=pass (imf12.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.179 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730937163; a=rsa-sha256; cv=none; b=lnhU1BEOSmMAOLMcRFyNfG/L9pkf2j/Va+TB2LxHIosR/6f3B/wvD8s2pfb23PRCl/rZid Py1Vr9PBVik3XoaZYBc6vgydOUZgxJpJH9lUXDHicV//+tW7jA7jgG9LdU0W+JJOK8uH1g g2+ImHoxzeS49E7GVwlmtRM+G7+++d8= Date: Wed, 6 Nov 2024 15:56:19 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1730937385; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WwjeiWb2K0qdNecBV8zVccaOFulKNeLja/T2sJGrqx8=; b=gXs7qhovA7Kr7NkqaAV458vaw1Tsdw7BPpxBHUmuXkh1bzfYyISZrFwFYbyJCN2Mdaj/yD g+xeVWd87RNCASIe40UyPESC+mFlTykpKcvxaEM7vSafAWwP39khI3cio31wXbpJ6wKfyu FDHWQfKX3CpEr3qvDtqKJLMSQopZlEs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Joanne Koong Cc: Bernd Schubert , Jingbo Xu , Miklos Szeredi , linux-fsdevel@vger.kernel.org, josef@toxicpanda.com, hannes@cmpxchg.org, linux-mm@kvack.org, kernel-team@meta.com, Vlastimil Babka Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree Message-ID: References: <4hwdxhdxgjyxgxutzggny4isnb45jxtump7j7tzzv6paaqg2lr@55sguz7y4hu7> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 79B224001B X-Stat-Signature: fm6fxw74s1syapaykjf3phguj6ru6bzn X-Rspam-User: X-HE-Tag: 1730937371-885501 X-HE-Meta: U2FsdGVkX1/jb+aZd94PEdS3VIoEFYvtruJunGCoTXFFRaJ6qq1l8zwJCu9kEZjWewDbe560+B8zPK5Mx0E1OANGBSnflzFr3RH1ihw/2udvEjZgRWywHKyXNLL0x+uZtNFc9RcS+nkOKIBx5uCIAIn+P2lg9ZULcUa3VU9OXJJgqMfxlZJE6zo+erGAlKAyatOyIL8W1Nef8B1HroqA+CuoCt8YmlmLEYADA/PjV0WBTJl7drWZwN2eiI5ZqjDgkfNNTOtQ0jMGNoH21i4FbWt20PL8dOp5x/svI+YBOcGJkanuzoNUno65zTrMlMVAh4bOJjif125Phrvu2BvVELfBC4gMeJADw0wlAddlS2DZ9h7TrRX5Fj8OsNgTUuj1tyAKrrmXuMHB0q0ZzTTEejjApd7loD/UgLrtUazYkMkY9uQ8pxarMRos1wfTLNSUoZf70HHwEsAd4PhEd1nUkfRBjT9ygNmVKPZUuVcVZjjba6tYlN01qaSRVKFvLKlMZ30nx2FvC/MqqkIQ13p7ptOsbRaqQo7ohu/JEj3ACcW1niAWTl05oazuxBr9nYBdEBS4NxnNgJ69/rUmIRFlJxPXpE/yY+xrCiM5r8hX6ZkAYUimYcqkEL/khIDRfDZSf1df9yQDSitXPyIVe20PRdwSuM1B9Bx8iyjr3q/FzO7EKyG3GyjqXNSs3L9TfdSbUc8yRcPNT2kdzlNJ7U/UGmrE4oUjumYrGT9H2IP91wBfeWWj8A1Pi/vVSMnz6yYzeMgy4ouqXTt4f4JQa42C0YLVBhteKvTRdkBceXDJo3GI21u9ln9h0ccQT5Lir8Nlq0T47rsW3nuMYYhDYBnvJYU8bWsq6e2m9WLuKCOXwwsfJSI5IeOEvDFZjb9n9hCiZhwoMYVnU8H2EBYmG5W0dK4QbwurhTr/I0YedY5kzN+C3hW7AlNQCA2mfOjhZrqbocSPSZG9hH08UXZf/BR bBZCBRFE TTXwDWS0zTj75EeKrAanuoaTLDEiikRvPAeOxYbMXaAkG4vtnlZ7qDx2WAqwqQ79pGnIS+QsRx1EVUgAL9WtF45TeRi6Ld6qyEzAamJMt0CP0+d+nFcc6ZddpwTNZGRfMLeYBDW6asiGTQRAzO+In8J3eaSkXcbTTl6cUHRqeojE9F2U= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Nov 06, 2024 at 03:37:11PM -0800, Joanne Koong wrote: > On Thu, Oct 31, 2024 at 3:38 PM Shakeel Butt wrote: > > > > On Thu, Oct 31, 2024 at 02:52:57PM GMT, Joanne Koong wrote: > > > On Thu, Oct 31, 2024 at 1:06 PM Shakeel Butt wrote: > > > > > > > > On Thu, Oct 31, 2024 at 12:06:49PM GMT, Joanne Koong wrote: > > > > > On Wed, Oct 30, 2024 at 5:30 PM Shakeel Butt wrote: > > > > [...] > > > > > > > > > > > > Memory pool is a bit confusing term here. Most probably you are asking > > > > > > about the migrate type of the page block from which tmp page is > > > > > > allocated from. In a normal system, tmp page would be allocated from page > > > > > > block with MIGRATE_UNMOVABLE migrate type while the page cache page, it > > > > > > depends on what gfp flag was used for its allocation. What does fuse fs > > > > > > use? GFP_HIGHUSER_MOVABLE or something else? Under low memory situation > > > > > > allocations can get mixed up with different migrate types. > > > > > > > > > > > > > > > > I believe it's GFP_HIGHUSER_MOVABLE for the page cache pages since > > > > > fuse doesn't set any additional gfp masks on the inode mapping. > > > > > > > > > > Could we just allocate the fuse writeback pages with GFP_HIGHUSER > > > > > instead of GFP_HIGHUSER_MOVABLE? That would be in fuse_write_begin() > > > > > where we pass in the gfp mask to __filemap_get_folio(). I think this > > > > > would give us the same behavior memory-wise as what the tmp pages > > > > > currently do, > > > > > > > > I don't think it would be the same behavior. From what I understand the > > > > liftime of the tmp page is from the start of the writeback till the ack > > > > from the fuse server that writeback is done. While the lifetime of the > > > > page of the page cache can be arbitrarily large. We should just make it > > > > unmovable for its lifetime. I think it is fine to make the page > > > > unmovable during the writeback. We should not try to optimize for the > > > > bad or buggy behavior of fuse server. > > > > > > > > Regarding the avoidance of wait on writeback for fuse folios, I think we > > > > can handle the migration similar to how you are handling reclaim and in > > > > addition we can add a WARN() in folio_wait_writeback() if the kernel ever > > > > sees a fuse folio in that function. > > > > > > Awesome, this is what I'm planning to do in v3 to address migration then: > > > > > > 1) in migrate_folio_unmap(), only call "folio_wait_writeback(src);" if > > > src->mapping does not have the AS_NO_WRITEBACK_WAIT bit set on it (eg > > > fuse folios will have that AS_NO_WRITEBACK_WAIT bit set) > > > > > > 2) in the fuse filesystem's implementation of the > > > mapping->a_ops->migrate_folio callback, return -EAGAIN if the folio is > > > under writeback. > > > > 3) Add WARN_ONCE() in folio_wait_writeback() if folio->mapping has > > AS_NO_WRITEBACK_WAIT set and return without waiting. > > For v3, I'm going to change AS_NO_WRITEBACK_RECLAIM to > AS_WRITEBACK_MAY_BLOCK and skip 3) because 3) may be too restrictive. > For example, for the sync_file_range() syscall, we do want to wait on > writeback - it's ok in this case to call folio_wait_writeback() on a > fuse folio since the caller would have intentionally passed in a fuse > fd to sync_file_range(). > Sounds good.