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 311C9C3ABAA for ; Fri, 2 May 2025 14:33:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE0BD6B0089; Fri, 2 May 2025 10:33:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A8CF76B008C; Fri, 2 May 2025 10:33:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 953FC6B0092; Fri, 2 May 2025 10:33:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6BD056B0089 for ; Fri, 2 May 2025 10:33:31 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DFF0A121B6A for ; Fri, 2 May 2025 14:33:31 +0000 (UTC) X-FDA: 83398211022.05.AA9781A Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by imf11.hostedemail.com (Postfix) with ESMTP id 3788240004 for ; Fri, 2 May 2025 14:33:29 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=DWdJ6Iff; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf11.hostedemail.com: domain of thomas.hellstrom@linux.intel.com has no SPF policy when checking 198.175.65.9) smtp.mailfrom=thomas.hellstrom@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746196409; a=rsa-sha256; cv=none; b=EXUxmVGZAgu3MdtvYdTie7qdich0vpkW4eJqq+PGrqLqtmcRrINtSvWOOVvkIgf9A0DD2K C3OKmPZzBTqqfl6YIw2DZG1FrppOkQFJigZGaCdFfDbLJFSzvMjG+UEPoPERXng950F56b qrt/iGBU1kXp2jzGEOzP8AIIU/DcMHE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746196409; 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=6N6Kw9sUqIXQKrTHQi1jSYjXPBYCbYpjjpS8eZQO+cc=; b=qRFTbF/Mj17ozEn37o9THyPTKofYXGwRF2jaDhms/pBLZ6uhj/vYo2e7wvoYBRfmPxalla tFTYl3oP1EQIlcCypiTZU3fcCvsMSjv7taSUm8PZCBv1ODur5vq4a5Pp6VBB1jPz+ucnyT DW5GwNGMwFnrNwzd1tjYajNXAvHa7GQ= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=DWdJ6Iff; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf11.hostedemail.com: domain of thomas.hellstrom@linux.intel.com has no SPF policy when checking 198.175.65.9) smtp.mailfrom=thomas.hellstrom@linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1746196409; x=1777732409; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=v5Rp66tCR2rfRjAtXWG6b4cJR5z56dbvWtUuTIKvNmA=; b=DWdJ6IffS/dhERsMIwHAX6Ke0XDLtJ6vMy4wdZwTNLAHZqTOBQB+fUAl jjZ5ekRQhF9BJtPUIVL5+QEckBN2zj9K0sn7heiyEy5JhOlZdAQ4ROPLH cHxyPm+M00QzuLwS5xvfN0H0Lshin6RJBByHrjhfe2CaALGdOdezLG/LM 7g6yPSwdCx/UQoyZfZxiTZ4m37HSYQugLQVkoQ/4XIX1wXUJ4gpFKt3Ob cc3KCs+IUo0jBX+nsLM88IyjdavuAHcM/X8vR0vQdsRvpe+wyf9LtdGQi 9jojGZTVN1+Oymqvc7keMlSGYveKRPlBVBMFJhpyeWxrm0lk5lM3j1J02 A==; X-CSE-ConnectionGUID: 0TfcbWsPSNGDJ3OScVmRBg== X-CSE-MsgGUID: VB3iaEKcToqHDaVr1AfTKg== X-IronPort-AV: E=McAfee;i="6700,10204,11421"; a="70382633" X-IronPort-AV: E=Sophos;i="6.15,256,1739865600"; d="scan'208";a="70382633" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 May 2025 07:33:28 -0700 X-CSE-ConnectionGUID: drzra865TBe7hccIYwHQ6w== X-CSE-MsgGUID: +aQln23+R/+E76SOFmi5qQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,256,1739865600"; d="scan'208";a="139832217" Received: from sschumil-mobl2.ger.corp.intel.com (HELO [10.245.246.151]) ([10.245.246.151]) by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 May 2025 07:33:26 -0700 Message-ID: <2238f487c71e07aa71ffd3b1b07e3deb72674d3b.camel@linux.intel.com> Subject: Re: [PATCH 11/11] fs: Remove aops->writepage From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Matthew Wilcox Cc: Fan Ni , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, intel-gfx@lists.freedesktop.org Date: Fri, 02 May 2025 16:33:23 +0200 In-Reply-To: References: <20250307135414.2987755-1-willy@infradead.org> <20250307135414.2987755-12-willy@infradead.org> <9937a6346feccb7ab739aff63a084f63f3ad4382.camel@linux.intel.com> Organization: Intel Sweden AB, Registration Number: 556189-6027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) MIME-Version: 1.0 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3788240004 X-Stat-Signature: hann4kxnoqwmj33bqw8iwmzr1yowunbb X-Rspam-User: X-HE-Tag: 1746196409-203670 X-HE-Meta: U2FsdGVkX1+JLiH08f1m1It+2S/CDO2t31ymcAVUCit1rprcVB/2SRRhJCcorz6yXrydsZM0yrRakvSBtn6WWbemWPMbvSDyKUIpBZhnzM2Zkw0ixSabL+Fh+kmgFDjFdz1x057jVSC48cp7XLQrbBn9/gF3Ov7j/9F2S1J59o6IOzO0KNj4dQzc1T8A2n0BPWOx29J4vYA7JBh0fX2pXHm/kirnVvj0RBjUQltczaWTDtLF46V2DX9k/YgWIWYqzvYAczYwGUL4VX79a/hE4FM+DuI5BjhTVexu96lAj04hDRMo0BxRZm6To7utNftahqVuaAMaoRDbnitJ4ipYQdApCBn8V+u53cVryAFUgFwCO9tVW7NKkiPPsp6Lxp8bmZBbX3oRuvCigxmLRUyzelHqOcynQ6VmYBo/MN58hNGTjknNiMOHmhg17WHc6+mzIPWdaoxMMM6NdU+qaNn09EK6GcJnUGX6uQQYMDf3nfmUpAbv6RZWqLhWdz1VICjnjT3eoP2ub7/x2ChXKDUsriKPPEW2a6LlyvKly+i58yW0E72ibBjO8Xo83aXbpzWnKWpJpuBvqUNWCk99fnuRabun/O56wwf5rf71TGU76OC3T+jbLAqnH2/wVPgNeRmNiy0/zVcWnuUcdmom3GMj/wrXNXRVYAUci/uB94EOpr3GV77/2BMb50DPCpCKMeQAyJr2aCwNmrcN+a/br6FwBHi69qogKlcSRdKCSddcW4e+mipQGYNvJnK7U0MFEg0awL4tYZjiX++ie7XZ3Tk9FyYmSmHP+AIVzz75H5Z66d8uCjrDPGcUdGl8I4MSIgH6uGNPz0quB3c7ue5osN+jwcX1Jst7lzbGcq5rev8qcUsVKMzP9x3AtSUKSrdoVhxOkwETqG9WzpXnrgJS7SyqZzbfh9g/cvld/8yj7Osc85Ghq3wt6enl/gQgZCWwbm9sm9qdiS4fZ6ihbgzoxzY 2ga9pys6 HQy/Rr0VssLIRFu4u9RqRrK0Ov1RdS5WrZtWdfCSmPCXQhILQkSa+1kcJwTU7ofq8ojz9sGfHb3/vJfFCZ+XVZjaOeCq42PnVqK73l0vJRT1ltANHFfn+d+Lgdv8cCQD718Ku5MSyawOwqPkAJjVacsP4sxjSAmbh9X1S/PeMlFnUT5HbeELk6kAaGL23f5AWeuRHtaBtRlTuV5NJbw6MNpvKiwYpFhWjjtfvNN3aOGwCOV3uT+p/mlngrBUwq8nIHhUblf7mLTRQeWRta228y9jCjsP8HhK54nTy2yz8IR7XfZA= 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: Hi, Matthew, On Tue, 2025-04-01 at 17:26 +0100, Matthew Wilcox wrote: > On Tue, Mar 18, 2025 at 09:10:38AM +0100, Thomas Hellstr=C3=B6m wrote: > > On Mon, 2025-03-17 at 22:30 +0000, Matthew Wilcox wrote: > > > This patch fixes the compilation problem.=C2=A0 But I don't understan= d > > > why > > > it's messing with the reclaim flag.=C2=A0 Thomas, can you explain? > >=20 > > Hi, Sorry for not responding earlier. The patch that uses > > writepage() > > here has been around for quite some time waiting for reviews / acks > > so > > I failed to notice that it's going away. >=20 > My turn to be sorry for dropping this conversation ... Once again my turn. This disappeared in the mail flood. Sorry about that. >=20 > > Anyway the reclaim flag clearing follows that of pageout() in > > vmscan.c > > which was also the case for the i915_gem_shmem.c usage in > > __shmem_writeback(). My understanding was that if the writeback was > > already completed at that point, the reclaim flag was no longer > > desirable. >=20 > I think the question is really why you're setting it in the first > place. > Setting the reclaim flag indicates that you want the folio removed > from > the page cache as soon as possible.=C2=A0 So when the shmem swapout has been called, My understanding was that the page had been moved from the page cache to the swap cache and now written out to disc and this is all part of reclaim. When TTM reaches this part of the code, it's always called from a shrinker with the aim of freeing up memory as soon as possible. So if this is incorrect or unsuitable usage of the reclaim flag, we should of course remove the manipulation of it. (IIRC I was also a bit confused as to why it didn't seem to be protected by a lock in the callsites I looked at)=C2=A0 __shmem_writeback() in i915_gem_shmem.c and pageout() in mm/vmscan.c Thanks, Thomas > Other changes in flight are about > to make this more aggressive --=C2=A0 instead of waiting for the folio to > reach the end of the writeout queue, it'll be removed upon I/O > completion. >=20 > It doesn't seem to me that this is what you actually want for TTM, > but perhaps I've misunderstood the intent of the code.