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 23384E67489 for ; Thu, 31 Oct 2024 22:38:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 85C8A6B0092; Thu, 31 Oct 2024 18:38:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 80C746B0095; Thu, 31 Oct 2024 18:38:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B7546B0096; Thu, 31 Oct 2024 18:38:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4E3E06B0092 for ; Thu, 31 Oct 2024 18:38:19 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9EE81C199F for ; Thu, 31 Oct 2024 22:38:18 +0000 (UTC) X-FDA: 82735362024.29.060FEE4 Received: from out-182.mta0.migadu.com (out-182.mta0.migadu.com [91.218.175.182]) by imf21.hostedemail.com (Postfix) with ESMTP id 53A441C0024 for ; Thu, 31 Oct 2024 22:37:24 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=iRM13131; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf21.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.182 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730414134; 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=74hfOt/lovYKoEC45qaB+42kzXinawa2j3XQtAHYyFk=; b=OpQs9HjxtNbiohQcr6SkhCAPoXUNJGMfmAV68GIkoXr5OKewTcAemmRIJG2I3hRuQ+2BAR 1qBpm/cSdz9/nV4Oz2mDr7YcscPDTPjKPEWorbyoIw/56xEyD19E31JnV/0CN09MOEyEjX Oyp9L4CUyOK4syyMUngFvQ5mza0MBWY= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=iRM13131; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf21.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.182 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730414134; a=rsa-sha256; cv=none; b=pEzPKiriGqLbngCnd090MzBfJ/HUW7bxRdsgChECywz0utCKhk7tGEWcYUO0dbkk6tRgRE R4mz8Cy9arbQlXBNoyCDLDN0yjnwTyKp4S13m0LcTAvjy19PV+m9UlXUhajh6Z4eVK807E qfK2ZYzpvJWOVj6SQ5YqBKtJyS4L2+8= Date: Thu, 31 Oct 2024 15:38:04 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1730414291; 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=74hfOt/lovYKoEC45qaB+42kzXinawa2j3XQtAHYyFk=; b=iRM13131QsDUGMtXwAkzV5OvK/9XPSdi/CE9XIu/2W7LzSrhw1f7pI8glxlDDZYFwjHmve 1lgOjPtdO4MT3mVWYcXRdjttDeEAb4ZZeC2wGyqe5zosxcFWneRn13ERYc29rTC8shpsDV RbeU2F7cCTM8a7TgH3rOzsJ4ruqzFN0= 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: rspam04 X-Rspamd-Queue-Id: 53A441C0024 X-Stat-Signature: dfhjzk94qez9s5apsqe5pawtq8oe8ys3 X-Rspam-User: X-HE-Tag: 1730414244-659085 X-HE-Meta: U2FsdGVkX1+jPu83oTtUPjMAYKTu3H2Qq8/N302a+LTUu9LqKIKzLHFFkQfotUEEOj7XvfYJp7QDCF7Jqz4cn5qNzfZa1n9QCN+up+LVwlDDkZdOzkukpQqc0o3fVU3KVZ3kP1FU7ZNBspNaT/Hl7ZYsdwOIch46C9iEuJtcoEKN6vmz1ypgU7oH8MTJadakX3RwieM73wVpXH8UlKiI+xIvPoIfvvZD8ywZDlcBRH3LBb0EAp8Pv6wWsL1fS1Ss37hsg9IAw4UR11h2MiE/UN9mVtctvTpv9N2SmntwBuuq+FyaAG4UIF7y3XZK2xHJAakCFcaDcyS6/zNRdJnfejk8ZeNw44w5iNlhlKVWUoaFJ/Nr+uLrOWTIEOYNMl0fPPnRfaJrg3yP9yjjgJLdxPyFicAY84qms8OZrQ/RYiZBMYX7jH67BqBppZgIhUhL28Q08MbjDqvmUtMnQ6kVq6N7TGGULx4e/UclTaEt47jrG9gu4OxvdpoIdYimH66xFHU26dycvloQ5hM78yPrjB52odrszoFmjd2SVssWt5TdRENi2JN8pg8oGNlnd2wJ9CeuyzzOxv7tYadeldF7iPHW/NUNv6klHJJIY8HveJhYxjyVJZdpJdwF/WIgNIx3YpKlBGeM9R+3efxkkdm5NKBMWjUEsKn9YSF4SQd1kvno6qKLhGYI37U+ah9kQvTl0XQwYm4LWts1Q3unz3gmRLZgZcRexQi2BaoOj6v3NSI8Svu7lp71VUXMJZO5bsiMe3Sij4myyaCKYGw7KI4atgGNGTN8e1bjIpuZiujRPat9imEKy3/qdtKpmrK95VBAwsUISMTKXkGWcOGXd6LU/OFyJNSCmzSax+XOgsCaMkJlzFyj41N1YSxxRHjF4dAt/8H5MzvUrS6w1hWTko3//GVvWn10ZbBV73g/GIlTVZp41Z8AYVZVvsFGnDaZTLPgLGUA9axWIyvYlpi79Rw uBPc9H+n 3T7CAhsP7iUhlSIn4ftBPxbwiC/nzo5p5Taz2LGhlZo69jonVqwBE6VfpxJquWIYiHSRu6jQuX95fS65MCmr7Ar9auEQJ4wUP2ZQFwHWo0e4El9+Mn4TTkW2Pa1jAfHH7wxbhcWTUyxwibdj0ljpEw6uihx2jVQ6NfER6Cf10Fpy/O70= 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 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. > > Does this sound good? Yes.