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 53642D5CC91 for ; Thu, 31 Oct 2024 00:31:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DCCD56B00A0; Wed, 30 Oct 2024 20:31:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D54FA6B00A1; Wed, 30 Oct 2024 20:31:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF68A6B00A3; Wed, 30 Oct 2024 20:31:03 -0400 (EDT) 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 9D6006B00A0 for ; Wed, 30 Oct 2024 20:31:03 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 43AD2161128 for ; Thu, 31 Oct 2024 00:31:03 +0000 (UTC) X-FDA: 82732016766.26.67288F0 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) by imf10.hostedemail.com (Postfix) with ESMTP id 8203FC001F for ; Thu, 31 Oct 2024 00:30:49 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=vtJrnziU; spf=pass (imf10.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.174 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=1730334617; 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=uG209TnvILyBQP4D3chubF5E2Ylyx7KK58n/MtjoAMw=; b=1Lu18Ww9anzw/XlZADsP4bffHl3jDGT2BXqw2jgFX94HvNFr0UpDOgOoa17zQaLFHd07hI gdxRBstvTZpxAcu/9N1EJjZKGKVu52t8y1XoXCuUayZwP4k80hUQtV+i0UJzjHbEkzUT5o o5r+sW/2Ws6pE2mI7AZQa2Ip5GyvHz8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730334617; a=rsa-sha256; cv=none; b=ENTxTqIlp8t9WsRT4ji7GBK8d9tVP34XSzC7bNQxzyKeJloONMgIrUZ+FNHoJKNcqrPG32 QSU90941e3Zuohk3Q6WDix8Jabnev0FibO//TIuIh1Ad/daQY9HvGoKOZxZ/xSqOLK2QQQ ryuL+ESzbEPKutoGr7ySH0EMoXb4nKY= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=vtJrnziU; spf=pass (imf10.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 30 Oct 2024 17:30:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1730334658; 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=uG209TnvILyBQP4D3chubF5E2Ylyx7KK58n/MtjoAMw=; b=vtJrnziUcHbfICwEOPH6nzT0/Un49Be1ClRYr7IMpfX42Axs6pawEhyI2W7PeeDNqWhMEV DpxINkyLNIiraH8JWBFtDGnhPFhiGwmpC9HDwprsLw2YNkgOdk/HSiaYv9TS64r4imXVlr t5747ggqqzHJHIl/wlf3/i554Qb9+Ns= 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: <4hwdxhdxgjyxgxutzggny4isnb45jxtump7j7tzzv6paaqg2lr@55sguz7y4hu7> References: <0c3e6a4c-b04e-4af7-ae85-a69180d25744@fastmail.fm> <023c4bab-0eb6-45c5-9a42-d8fda0abec02@fastmail.fm> 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-Stat-Signature: 15fgx5wj39yj6u3yynjmwzi4kan4wi4w X-Rspam-User: X-Rspamd-Queue-Id: 8203FC001F X-Rspamd-Server: rspam02 X-HE-Tag: 1730334649-415409 X-HE-Meta: U2FsdGVkX19PurSOiCBH4mYLFGot2fBwgXy8KDqFudhNoAXt7qqmaj4q3J/cVN3v2TOmCxvvqJ+muaOe1uts+J+7R359QJXbBP/hWMCkUoFeBrmRJhK9yla+3sN+gYNOGhJwa2cOYgmht10vsohvtk6xIMmsFTYNiHcZSId6qmoQPck7fKaOb5iU3uohdL2/ciAJ6Iij82++AJrrSzyO6HRlWpZMMkEl3WyeNx6XLawQS/kPXBEi8mX9V9tMuBLLw5lBfYSi68UBGwtRfMUMAiZiG5XWG6eC/mmIPRE81I7gJGfoByDz9RxsiVFfckfWMme5l44a5lxfJ84yh1K8vgwi8Ne1kqkN6b9r5tzyKCSOHz2LrK4igHuCZnY1QI5PZoRslF6cT6W8GWb7WZYdeprM8+XXs8dglUF4oXxiAUBN4IVfa5thNP/qDX40B41l1Qg7KBOnVAElrS7+QHwwXQe/AWDmN1ECbNyVtZBgu0wGu07w65TcehaE9aICS0n4bk9jJAxJ1W5WWvwgv5D31ysajx8+BH9ZwL1fw1wED7l4VjDKBkH2GoEQJvQ+lMvohdsz1zdLJGe7PYrKb0aylVq9CC0LbZFYblDRgwh+v9sjMruGFVPx3GiBGlTUudosEwte22PYdw4kreVRLIWtDidRUN7UuRzp8HpMK5CLweWX68ly1Ccp3ctuF8yR3wO732Gmi+ofGFo2yxQKEWinC+7l55yHJIRn9/s9x/O4QOBG5aYOo4aV97G0GUJ9h+/aHONllv4NoxufvodZN0D7D+EWBPeY/D1HETPXUap6V9lpVb6hzitedHpyFthJcJnk/gWxectyTbPJHg2iW843gd1lyNejfXyYX/yQ2y0fMMgXc4erEVsvqObAGmAYT73/7KShAlJsMRSTHjuEgVqbeJavIJGVoJz86DoqwBdsYU4zBwC+MBCHOazxLpvlmhZFymf4j5tYYel8UBILlpF snRCwdD1 uw5VA6rsrbEWSRPl90b53Unf+vy433cKtF311JCvkLWYMnKYN2qxAISaP5NNSNHWnSuYbc/tNg5/75skRs8jNycJD6qfMIdJSJB/gEQYb5Hli9wkQN9QzFDylF/1CEP6l2tzpmjw75hAKDLXJXT+pMvQJRlY1X5Kp5+IUac2x2ZR6ejM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, 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 03:51:08PM GMT, Joanne Koong wrote: > On Wed, Oct 30, 2024 at 3:17 PM 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 AM Bernd Schubert > > >> wrote: > > >>> > > >>> > > >>> Hmm, if tmp pages can be compacted, isn't that a problem for splice? > > >>> 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 pages > > >> being used in splice. Shakeel, do you know the answer to this? > > >> > > > > > > Sorry for the late response. I still have to go through other unanswered > > > 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 ignoring > > 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. > > 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.