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 E0898C02195 for ; Mon, 3 Feb 2025 08:40:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5EDBA6B0082; Mon, 3 Feb 2025 03:40:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 59D3B6B0083; Mon, 3 Feb 2025 03:40:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 464966B0085; Mon, 3 Feb 2025 03:40:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 269CF6B0082 for ; Mon, 3 Feb 2025 03:40:18 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EA96F1A2470 for ; Mon, 3 Feb 2025 08:40:12 +0000 (UTC) X-FDA: 83077986264.26.1EAF138 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) by imf24.hostedemail.com (Postfix) with ESMTP id 1C0BC180010 for ; Mon, 3 Feb 2025 08:40:09 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=UvtE2Zkp; spf=none (imf24.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.198.163.16) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738572010; 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=shYb83n7aEttSR3+WZ6LWhcsTd1K1+i+drhD7gmu1IM=; b=NXY0LCkmR5dk3dFHv11GDI/ig1+5HK/fKkdNAYrp+uEurwm0ZEFDb2a8Xy/NNnJGg6Cyvk 0iAd5ezBzyAJTdB8Z9EBPn9FDqyygVN9SjR+EzBIO92jH+GvOi7pUrDr+0EVYGk3NT941Z JlXa0IGSS57ZsNLBNmU7nZrKXR2IMSE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738572010; a=rsa-sha256; cv=none; b=wZ+nDXH112USGWxH9jhM2Mo7l8iP5sp5wYrMykEoOGDiMSilZMPe0+VEPEuP3k3oweWw5i UGX7cQJ0SKoL7HEpBx+JUmDhIa10sX5L4OYgaPRpWp5lYKQLP5cqJSDjIsdX5VR+qdiXK7 GYsWhoP/bKzAOK4GimCI8INaVC866Ng= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=UvtE2Zkp; spf=none (imf24.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.198.163.16) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1738572010; x=1770108010; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=7nb8HRa0cFbzBFBnN4bI0GsAQD01kUzx8HOrS7jz88s=; b=UvtE2Zkp/BlXiRpWZVh7LTzuy2/o4Yt/2c5r22aykUwyu3JHRHA1seTR 2X9niUKJzSowi+1JBtfxI8YITYE19b+ENwAsRmiaLrmwDFKG/CLfn1Cuo TjA0KG/tfFEcGm5Y/v9PSD3kndg1bNfW3SH4LER6g0bzjSS29iChpzPEv v04s+ibO6DmIw9krnEwvABBwyBdDomj0wY0dXCDL4BstPyqfqImnKWMke 7Rpg2T7TjHUmr6jvPeiRVpd+HWQ0UOhWsPgeT+YKET71nITblPT59kZzW QRMvGe7FLGnZpuR0gkohlGLqHSZXL/24O7V+5ILRZGXwEtJvJPbSf5ydt w==; X-CSE-ConnectionGUID: LTunLdc1Ra6cP76nvuFH0w== X-CSE-MsgGUID: mho8oJfPTyy7wpcysQLWEw== X-IronPort-AV: E=McAfee;i="6700,10204,11334"; a="26657670" X-IronPort-AV: E=Sophos;i="6.13,255,1732608000"; d="scan'208";a="26657670" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Feb 2025 00:40:08 -0800 X-CSE-ConnectionGUID: /pEpuut2SbaCB2xPbjWkbA== X-CSE-MsgGUID: th6k5N9TR0e9cGBt5VIk/w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,255,1732608000"; d="scan'208";a="141100533" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa002.jf.intel.com with ESMTP; 03 Feb 2025 00:40:00 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id CF435214; Mon, 03 Feb 2025 10:39:58 +0200 (EET) Date: Mon, 3 Feb 2025 10:39:58 +0200 From: "Kirill A. Shutemov" To: Kairui Song Cc: Andrew Morton , "Matthew Wilcox (Oracle)" , Jens Axboe , "Jason A. Donenfeld" , Andi Shyti , Chengming Zhou , Christian Brauner , Christophe Leroy , Dan Carpenter , David Airlie , David Hildenbrand , Hao Ge , Jani Nikula , Johannes Weiner , Joonas Lahtinen , Josef Bacik , Masami Hiramatsu , Mathieu Desnoyers , Miklos Szeredi , Nhat Pham , Oscar Salvador , Ran Xiaokai , Rodrigo Vivi , Simona Vetter , Steven Rostedt , Tvrtko Ursulin , Vlastimil Babka , Yosry Ahmed , Yu Zhao , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCHv3 06/11] mm/vmscan: Use PG_dropbehind instead of PG_reclaim Message-ID: <42h65xowqe36eymr6pcomo7wzpe26kzwvyzg44hftqqczc5n6y@w2z5wvdrvktm> References: <20250130100050.1868208-1-kirill.shutemov@linux.intel.com> <20250130100050.1868208-7-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: btzqubykrwxs4b6671d8z1t3chf41443 X-Rspamd-Queue-Id: 1C0BC180010 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1738572009-90591 X-HE-Meta: U2FsdGVkX1/hTaTAoaG4boBGdPxA9cIScCH6BA+hKpm3FLdsMPG0nlOxpdhrxLHw2WaA5Bbk14wsZlBhjLqckd6qNyTJsWySMAiWUlF6EIhLT3OTv8mkoiLIOXKZB/TrWQH6BWSy+ngAcmTFv2tNDUzmrb9V4cSqqzIQkBXq16RhW/UgFFNzG51CWPNElFSnX5FW2+S22lo4TaQ6YDySB/TMLy83RvCEWB8WUw5fgIZYcJ4BTU0l6LcRqCdQjsPf/dw/vrFvt8Ca1+PZdDc9fk/40ddJsFZ1z65hhY5Kn425NPKmgaRv791ufyRnoKh5VevfJrM7jsO8diV7Ded4Qkq/VbT1XdxXTwIBHnE+OCQgNC4zPneifOg0om4pa+nJplGviXaMsljoDJZDxI9I4Nm2BPt2CPcopo4YP1Q1BcvUgqtofYEMc1Q75ZB0MNglyHiE7xwSZTzFV5yslBvVEnjqMi7HuOTMDmJM4mrrTUxWKYxvcduYvNiX90AMwM7uQDbXaNGMbUtNXgp+L4ZKqZnEbbyzBmdw0uvk2gU0AnB1uJk4oQNPfCn5qq7ZoFMC5/CHW/rTl7EEjsA6wl9TVrfzvYnGn8wPYWIOiLtiErY1sKn7bNIm5boQtnBoFdEnG/1qo4PPbSYLhvkjvO8inhmE9FSH+j3xbD1PdVOTWMoFf3M9I/INscUgWHdldkHjEbjL396hbdFFFsloNUATZGn2lRSbeV/r8MpNXpfJafAifdqM8kHQPA5m5ur59RJEFlKd8PgXv0EjaQzZoFcO2L9aeh1X2hQO/Epxzw7GVsw5cDJHP+NZTXiOqaUXUKW0Bp4hcfnnB7++0KAOONLMqHO8XEgjrNQFt/uQFUkgMu736j5DRhjaIBIsHgXZ2GSQahbmETkCvUAv/p3pfNiCxcdTEyUgbCryKiLk/wNwiIyLmiQWsJnlkTosR8soj84G+p7Lnvbeh+35Ef610P/ Exl/MnVL 0QV04gOVcl9nE4N7yDPbXYIMA07Rw11zgHg+FvypDfU9qKil3p7z29Zo0lSJ8KJoGGbgY/JPaTL1PdJdQzAlYKhwMbmUKmYIvsXbitV0x/2IhP6aK5mRujz9mpIu6DAoPLPkc6wI+o050Wf32k38ghnZz9MbBW2XnJHf3phUh8tAvlgpX61BCKWpCvoMBfMZpae6CiNj0IMsbm0f0O1QntcrMPQgx+2EP+wW8mX9mkBl0JJm7fA2k4bRQHNGG8c7FQT+IJtjsVfPRkDr9CtXdo/7ZR5z7Ou4q5CRjfi0tuKHBc/Th2SE1KZhALg== 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 Sat, Feb 01, 2025 at 04:01:43PM +0800, Kairui Song wrote: > On Thu, Jan 30, 2025 at 6:02 PM Kirill A. Shutemov > wrote: > > > > The recently introduced PG_dropbehind allows for freeing folios > > immediately after writeback. Unlike PG_reclaim, it does not need vmscan > > to be involved to get the folio freed. > > > > Instead of using folio_set_reclaim(), use folio_set_dropbehind() in > > pageout(). > > > > It is safe to leave PG_dropbehind on the folio if, for some reason > > (bug?), the folio is not in a writeback state after ->writepage(). > > In these cases, the kernel had to clear PG_reclaim as it shared a page > > flag bit with PG_readahead. > > > > Signed-off-by: Kirill A. Shutemov > > Acked-by: David Hildenbrand > > --- > > mm/vmscan.c | 9 +++------ > > 1 file changed, 3 insertions(+), 6 deletions(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index bc1826020159..c97adb0fdaa4 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -692,19 +692,16 @@ static pageout_t pageout(struct folio *folio, struct address_space *mapping, > > if (shmem_mapping(mapping) && folio_test_large(folio)) > > wbc.list = folio_list; > > > > - folio_set_reclaim(folio); > > + folio_set_dropbehind(folio); > > + > > res = mapping->a_ops->writepage(&folio->page, &wbc); > > if (res < 0) > > handle_write_error(mapping, folio, res); > > if (res == AOP_WRITEPAGE_ACTIVATE) { > > - folio_clear_reclaim(folio); > > + folio_clear_dropbehind(folio); > > return PAGE_ACTIVATE; > > } > > > > - if (!folio_test_writeback(folio)) { > > - /* synchronous write or broken a_ops? */ > > - folio_clear_reclaim(folio); > > - } > > trace_mm_vmscan_write_folio(folio); > > node_stat_add_folio(folio, NR_VMSCAN_WRITE); > > return PAGE_SUCCESS; > > -- > > 2.47.2 > > > > Hi, I'm seeing following panic with SWAP after this commit: > > [ 29.672319] Oops: general protection fault, probably for > non-canonical address 0xffff88909a3be3: 0000 [#1] PREEMPT SMP NOPTI > [ 29.675503] CPU: 82 UID: 0 PID: 5145 Comm: tar Kdump: loaded Not > tainted 6.13.0.ptch-g1fe9ea48ec98 #917 > [ 29.677508] Hardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015 > [ 29.678886] RIP: 0010:__lock_acquire+0x20/0x15d0 Ouch. I failed to trigger it my setup. Could you share your reproducer? > I'm testing with PROVE_LOCKING on. It seems folio_unmap_invalidate is > called for swapcache folio and it doesn't work well, following PATCH > on top of mm-unstable seems fix it well: Right. I don't understand swapping good enough. I missed this. > diff --git a/mm/filemap.c b/mm/filemap.c > index 4fe551037bf7..98493443d120 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -1605,8 +1605,9 @@ static void folio_end_reclaim_write(struct folio *folio) > * invalidation in that case. > */ > if (in_task() && folio_trylock(folio)) { > - if (folio->mapping) > - folio_unmap_invalidate(folio->mapping, folio, 0); > + struct address_space *mapping = folio_mapping(folio); > + if (mapping) > + folio_unmap_invalidate(mapping, folio, 0); > folio_unlock(folio); > } > } Once you do this, folio_unmap_invalidate() will never succeed for swapcache as folio->mapping != mapping check will always be true and it will fail with -EBUSY. I guess we need to do something similar to what __remove_mapping() does for swapcache folios. -- Kiryl Shutsemau / Kirill A. Shutemov