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 E7369D767FA for ; Thu, 31 Oct 2024 19:07:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C05B6B0085; Thu, 31 Oct 2024 15:07:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 76FB06B0088; Thu, 31 Oct 2024 15:07:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E8ED6B0089; Thu, 31 Oct 2024 15:07:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3D1156B0085 for ; Thu, 31 Oct 2024 15:07:04 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EEF5381886 for ; Thu, 31 Oct 2024 19:07:03 +0000 (UTC) X-FDA: 82734829632.02.B6DEF86 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf07.hostedemail.com (Postfix) with ESMTP id 193874001F for ; Thu, 31 Oct 2024 19:06:23 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YVznFpA6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730401566; a=rsa-sha256; cv=none; b=VY7XtpeWP6oJ9Eq9AXvAs9cgEoUc7GvhOr6uDOEGyXQti3/O2/3n/3VMi5u9k4XihQGfi3 Doo1KvvFe/oP60vrLBFGnCxM/Wr1ddNb8f2lXQ8OALUJWJtc99C7il6QtSN/1md4m076/E lzKLv3wQmZhPEiTDBMp0r5G20E8FCHA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YVznFpA6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730401566; 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=+RBphthZTBzrNiL2LY0HGqi6z0QMZ9zMdxDe6rHMSog=; b=FwfNjb6HFlrsH5OV1kbV0uUBpADZkJ7JXWRIlB//OXi0Qcd901tndnoedLAvcxf7wzXj5l WkH6c/9BTzIwZJvQfpIwOY4R3hZulhnPGtNuj0QfcP33qbd+NCVmPfE+cr+izp2m0Zt6/g G9p3FrlAHuSYS9tdZesBcjX9f3orzH0= Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-4608e389407so15626471cf.2 for ; Thu, 31 Oct 2024 12:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730401621; x=1731006421; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+RBphthZTBzrNiL2LY0HGqi6z0QMZ9zMdxDe6rHMSog=; b=YVznFpA6a711S+/fkN8JZvOawxR8KkXnIFrxV3/5wAm2gOZ7D8rcCg1Bjga1ySRx5b JD3BOfQ7mGrfGbA0NN5eN8V8Pg/ZgaM/CO222N7038c76QakJLKoPLLXZyLeFE7R1twS oW7vQbLfJdUvwRbumnToaXZoDJ4HXvz112pXbC+RLc44U5niTPnVWxgcUgp4EQ/GwIDj vzFR3IrFR8Q8jP09ZEViOgea/grC3FFEAxBhfMlq6+OmsGTj6PDMhvkan5yyn8PWUjg3 eNig4kFIRZExqAu8tX8x/2yIJIeUkcv3PF/rk0ZW9XzLxpP5qA18bI+e7YBEQHMd7iqL YF8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730401621; x=1731006421; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+RBphthZTBzrNiL2LY0HGqi6z0QMZ9zMdxDe6rHMSog=; b=oZNDPT2PfpR1ASed1qTHei2k1TFodKfa1R03M7uVe1t1wsw+bUAotnyJlgpfNKMPTx mPzKTUYGn7D2iyGCGVlsb6lC1dQFFZJaYn9/JO0WsC38GBXVHzFE4RRsI2X/J+AT45ht Oz+S+ODAtDPJbGqxyRDlK+WnT8hYQoJWXpx/SCGsL1eloWiOc6dVm+1Izmvg24k442ip 5b/TtmUjMbtbBxOqc7zltvy4isltWu42FcTIBC/V7w9Csnb2cJXCHZUo8GwDBe9cy/sj f/jFYGr43Mv7qfoDfF3rr+bUX1J9d8/tt5guHu22rMk41sUNdZk07aiCHmRtIbAsEIXg BQyQ== X-Forwarded-Encrypted: i=1; AJvYcCWuhJ3j+hG9bVDYR5ogu3EzWlWlPYscXSETMSl0x/tAI1DbOjFhkqiRZuA/SIUZ9JFWMHXWP0uc4g==@kvack.org X-Gm-Message-State: AOJu0Yy5mmMntqSvQaFoEgcuWWQ9YRxtZvt4fP0cPM+2lzbNCcOPtywU tG8u6xml3X/yqzn1W0FjeDkO+tU6VXb6OezQBHaQUmHbvKt3zAIIFd84eMUyE1C+1brPpRS/1K8 elUk+SZ6J01C5NdpTNZ4tcDk9QMo= X-Google-Smtp-Source: AGHT+IFQe7YwwYiFUuHl5+J6TIsFIBFvRkpXHd95086JeoaxLvFNgOwrDrya6Od0dp3CA0yY4qX/c1etlFDIihwWveo= X-Received: by 2002:a05:622a:1a85:b0:460:ac0c:8589 with SMTP id d75a77b69052e-4613c1971b5mr273002781cf.52.1730401621024; Thu, 31 Oct 2024 12:07:01 -0700 (PDT) MIME-Version: 1.0 References: <0c3e6a4c-b04e-4af7-ae85-a69180d25744@fastmail.fm> <023c4bab-0eb6-45c5-9a42-d8fda0abec02@fastmail.fm> <4hwdxhdxgjyxgxutzggny4isnb45jxtump7j7tzzv6paaqg2lr@55sguz7y4hu7> In-Reply-To: <4hwdxhdxgjyxgxutzggny4isnb45jxtump7j7tzzv6paaqg2lr@55sguz7y4hu7> From: Joanne Koong Date: Thu, 31 Oct 2024 12:06:49 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree To: Shakeel Butt 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 193874001F X-Rspamd-Server: rspam11 X-Stat-Signature: mmezqi3wd7qgd7ju4soyatkqbesstqgi X-HE-Tag: 1730401583-655497 X-HE-Meta: U2FsdGVkX1+Rz1vQ4JzNXxFxiwzoTYADcsZU6hbGsr6xIY8JJWQJNGaDJb2+Y2jObXOvSwjbGV6fk73sSeqpgtFf1lJEr7JNnzs52GjsbMo4bVfJsJkNt5cmEZHIBjS4TnufdxIzQ0saa/E1bY5fRiXDJTPV4NHG5zqmkKXuSg2ORY2DONqzHFGgcjCYZzoXzxtP0s0lsJm3ZKatKiF1DiUxcuB7JX3pMcUp+vCwUUjY4cEkFhbUBiBYqMT2EurhSbFUSLc/E+oyDo5cXjPC360/CucjG7c8YiG71iG2HqMfWwFDYt8mbiZK+Yh7JKXYVpOYOHoCU/0r7nTaoY6cku6Rl068hA7EVnBCDtIhMeepThqy+k49pYG1S+dVjeiqF5iBENBu4RAstvY1rwFt1eMl0fhf45PJu4aE62G2TZUCuxeSHF2Y6/ENJ+cTZfYtgSn47MjNn2W1z0COQnJM6ao+O4PkkPeheYSs1Ek9ojbB3xkfPj/DI4uBQWxBWu93EK+3WdrbdWT/zI48I1Juf+OvEUneV9tkEhvrghPNZYC3q+KnyN8D6ZxHIvn9HDUrLpV/q+Vxn8XhTW6ieTa3RKke/cXz3vfpwOeqKd0PALtOdIhG2nODuB1BdXK8cGu368wsai9jfEzarihvsEHDr2UQHHccD/DUQZWgzx5sz4tnuKIkqCgkgzqVMjHUtgG95fv0GANrg8No4uQt13u7VkZ9vHt7Q7T452HtoMOmXpII6LTLKkVWje+VgvmNF6ngCAa/TumugM7JJmpskkDH4d8yMvlXREUWxMMD4YYVH/vOPgA7sgLPeU7OdGnHwuywwCVc3e/vP2ns56EJ76D6b3VWAC8vb4CA3qezWKHFK1wJOrrj2EOyJOqxuNblVCv75OrdZwO1vmXWv01AKeuayighHYSwRY3hI7nZyDyatUw5gL7pxwAl0OK9QkGdFj7wtHPZ4e03ClkevHnUD7G h3Yymkcy B3bIBeoyae5/JQpKk4Wco0TqP8X9WtW9dEV2NKlSz+EDB7aE2B5LQUivSUeIPYjhMh/y1xqwgIcgIx0xqJLJSVzhbsN9YPTksETmtL4SdAgRy8bJ8RiaUzZQSKupU7IMKbz3/9uIq8X639Qu7QM3Gd2DDGJub0JfxhW0NiY62ZxsuWS7kBlUCH5u1AnWFnhqHdnIZZxO8L708TO8yqh5UZ+ZinoCRcqqMXKafxmbacOUbS6815lcJH29zkV9rMFve3MM9RrnYqYTg2lpOeKPK/UrB9xhVWNa82m01u/9PZ4ZyGDm+HduOoslx4PlDU2SSMRzy X-Bogosity: Ham, tests=bogofilter, spamicity=0.001166, 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, Oct 30, 2024 at 5:30=E2=80=AFPM Shakeel Butt wrote: > > On Wed, Oct 30, 2024 at 03:51:08PM GMT, Joanne Koong wrote: > > On Wed, Oct 30, 2024 at 3:17=E2=80=AFPM Bernd Schubert > > wrote: > > > > > > > > > > > > On 10/30/24 22:56, Shakeel Butt wrote: > > > > On Wed, Oct 30, 2024 at 10:35:47AM GMT, Joanne Koong wrote: > > > >> On Wed, Oct 30, 2024 at 10:27=E2=80=AFAM Bernd Schubert > > > >> wrote: > > > >>> > > > >>> > > > >>> Hmm, if tmp pages can be compacted, isn't that a problem for spli= ce? > > > >>> I.e. I don't understand what the difference between tmp page and > > > >>> write-back page for migration. > > > >>> > > > >> > > > >> That's a great question! I have no idea how compaction works for p= ages > > > >> being used in splice. Shakeel, do you know the answer to this? > > > >> > > > > > > > > Sorry for the late response. I still have to go through other unans= wered > > > > questions but let me answer this one quickly. From the way the tmp = pages > > > > are allocated, it does not seem like they are movable and thus are = not > > > > target for migration/compaction. > > > > > > > > The page with the writeback bit set is actually just a user memory = page > > > > cache which is moveable but due to, at the moment, under writeback = it > > > > temporarily becomes unmovable to not cause corruption. > > > > > > Thanks a lot for your quick reply Shakeel! (Actually very fast!). > > > > > > With that, it confirms what I wrote earlier - removing tmp and ignori= ng > > > fuse writeback pages in migration should not make any difference > > > regarding overall system performance. Unless I miss something, > > > more on the contrary as additional memory pressure expensive page > > > copying is being removed. > > > > > > > Thanks for the information Shakeel, and thanks Bernd for bringing up > > this point of discussion. > > > > Before I celebrate too prematurely, a few additional questions: > > You are asking hard questions, so CCed couple more folks to correct me > if I am wrong. > > > > > Are tmp pages (eg from folio_alloc(GFP_NOFS | __GFP_HIGHMEM, 0)) and > > page cache pages allocated from the same memory pool? Or are tmp pages > > allocated from a special memory pool that isn't meant to be > > compacted/optimized? > > 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, and would solve all our headaches regarding writeback potentially blocking page migration/compaction. Thanks, Joanne > > > > If they are allocated from the same memory pool, then it seems like > > there's no difference between tmp pages blocking a memory range from > > being compacted vs. a page cache page blocking a memory range from > > being compacted (by not clearing writeback). But if they are not > > allocated from the same pool, then it seems like the page cache page > > blocking migration could adversely affect general system performance > > in a way that the tmp page doesn't? > > I think irrespective of where the page is coming from, the page under > writeback is non-movable and can fragment the memory. The question that > is that worse than a tmp page fragmenting the memory, I am not sure. >