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 C825AC282EC for ; Mon, 17 Mar 2025 17:37:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E885F280003; Mon, 17 Mar 2025 13:37:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E0ADA280001; Mon, 17 Mar 2025 13:37:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD33F280003; Mon, 17 Mar 2025 13:37:18 -0400 (EDT) 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 ABBF7280001 for ; Mon, 17 Mar 2025 13:37:18 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 778808043C for ; Mon, 17 Mar 2025 17:37:20 +0000 (UTC) X-FDA: 83231749440.06.675BC2D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 9D755C0012 for ; Mon, 17 Mar 2025 17:37:18 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=rzscnuK1; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742233038; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9Ou07y19hHoFxJDO518GVLUCoDFD9+meowgcg3opOJs=; b=MT9l8Fknzpy4q2Mt4GW/Gkbh8htTj6GJ0fZELWxVvcPn4/WNZnIo6/f6KPj4eIZ1etlS3H ERb2pf5yayKzcJBQgSAB5V90FPy1Xu97ZJwD64v7bhXwFYqnLFc2wVGugNQUJ3J2o+Fk4g qUAHMdohwuPx/GLqiW/c1+AoPULLv2I= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=rzscnuK1; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742233038; a=rsa-sha256; cv=none; b=Ix/8nPthSDNzWPaXZlOun9RiOkt7iDR5/rqxwOo2Wq0i0U8gEuXI705yqLMI8p8p2ef3UF 7H1T3svxmjoMf2ziSygPxrnZNGKeTRDlJWls2M8cewMX+w4DV54aO6WQOzhDyQzZPnPdt8 HTOnq3dC/SaNNshpLm5up+F5uXX4x3g= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=9Ou07y19hHoFxJDO518GVLUCoDFD9+meowgcg3opOJs=; b=rzscnuK1zMwzFJZFB/omq+twj5 uGsJ49gL0G3JXWuh7y5gVl2slpnfjpCiBiLO8lggdVbGslS2SnMe+A+1VkD7Mf7MUfatb/P/xdDvI 4JtyUx/wcbz7qybn/iyt9iMTv+uhYaEJx6cXzSA/VHrtmwbr3CeW37wKo5zyXIli7UsOQakEPtWV6 EVERuV2BP2q4HwLhRcysK0bIYDU5n3E1MrH8OlfhOOxpkJ/tCmll/RpKgWJ574laqXcZBJsz/6f1T W+EyFd5q6SWEwN+6/w18wrK2+gzo+/3+zRBhmvbit0T05iDLtMfvURiejKY/X1sZ5kYMqY1067LGI 8P7PRP/A==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tuEOr-00000009E9R-0NwM for linux-mm@kvack.org; Mon, 17 Mar 2025 17:37:17 +0000 Date: Mon, 17 Mar 2025 17:37:16 +0000 From: Matthew Wilcox To: linux-mm@kvack.org Subject: Re: A plan for supporting PageMovable in 2025 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 9D755C0012 X-Stat-Signature: ukmwkc1qzbjiwhkmamu41hzm46hnw7e1 X-HE-Tag: 1742233038-289193 X-HE-Meta: U2FsdGVkX1/ZTmShYLTJPiIuRukAq6LR2WaA5OflS05BIMruV3TDGGmrXlp8y6zuEeVrLmAgPHgII2EzeMSWvyTO8tF9crwg0VH4oaxjDwvDwMzeHyBAMHB69jkk2Gajcyx/1uRa4QuuujPN0/qUgiZI2Nqv+Ah/frXyKUBOjCidg5HrbtErKcBXgjM/933pA3fThi2c9YD5P9rAd0DErOsMt27tYbh6h3k0myvJ7l14ZSAUylQdjYOwZI1W4aYoFDNEo3QzBp2RneOpNm4lFETxonEn4FDbm1iTohPlFd2mNHP7bxtAXjJPRUC9ZzBfqUicgD6lsaLjMxK81T5Aa6PXzU9YZJlLRg5AiIdgHoKTBaygUsxT+NqlcpdfelpmzITj1VU7fmeq0mQh07us7jb91Q24ZLJpCjwt1627TDJKHIg7jSPuR0mBDdrpJSEyZOFNdyGBeLD2gMsIvNTexWUVbFaENvB2OqUy0wwRLre9ZX5t21WDed3+e0SFIFR7q2Gm/TFZYXBpQhbK6L++ZNQdf/L/n/wwrS2sAKD5Tk6eYslouUhRHWvynhyNPUhR3QM0kJeHbMS9R99tp7DKOgbGgM1XOORvTER1vY/ZdAYxgbiJXn4ilw115xt3iNdwfeIwz6JYHHRutoXryUAboD2RU+IqzTMbeueEZTDC2LNSek71QZiOo0NkCUTrIfw8zP0rpoYltDkWLul+eR0wjkWI/V8FDjYsx5v8EnkWpvfAr/fih08F6rHE1bkNhV6WNk9X5h5QeL4cJn7nGCKhwuz0gpkoBHrRTb34MIdyFivojXN744Ziy+X46baIBQ6UeOJIXMILrvKK6CTVaDGivLK9vvjdwyD30eH3jemFGsknSmNeQqm/BDrZcDr2tc5qgvfczCRiWNRq9EKloYewNdXybPwUdWVR4VOpBKw6MRzFWBmFgeT8oVwgSvQpv+pWx2waofwLdpXnqxjnQs4 Jy/o2/Qc RJnuUjPUEPhiJvL/OyafmuUbWwfWwuuFuUbvoy32BSKPp60hGPY+B2AXSS3e1E5ITDiixDYTaWWiUNbILjI6TxaexiFkBRncakSK93/FvFDxh+uAq+b/Ugnmd8UIWDF1Zd46cRxILf7Ew0kntjXkeWIzmYYUPZuobyT584z3+2Cp7z+BkqAdu4iYXl6K+jkH6IieRhc6l3ECYDD0QR6X1S/tHFCSlWtUrHae8 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 Mon, Mar 17, 2025 at 05:00:03PM +0000, Matthew Wilcox wrote: > My proposal for movable non-folio pages is: > > * memdesc is used to point to struct movable_operations (these will > need to be aligned to 16 bytes, but I think that's fine) > * private is used to point to the next page in the list > * These pages are refcounted > * We retain a "lock" bit in page->flags > > The most disruptive part of this is that we can't use a list_head any > more. I don't think a singly-linked list is prohibitive, but either > we need to switch folios to also use a singly-linked list, or we need > to handle folios & movable pages separately. I think the former is > probably best. And of course, moments after sending this out I realise I didn't include how to handle zpdesc pages. zpdesc have their own memory descriptor (like folios do), so they can't use page->memdesc to point to their movable_ops. Either we can make zsmalloc_mops visible outside zsmalloc.c (which would prohibit zsmalloc being built as a module), or we can make struct zpdesc look like this: struct zpdesc { unsigned long flags; struct movable_operations *mops; struct zpdesc *next; atomic_t _refcount; ... }; so that the same code can handle both plain pages and zpdesc pages. It's a bit wasteful in that every zpdesc would contain exactly the same mops, but it saves playing games with symbol_get() or having zsmalloc fill in a zpdesc_mops pointer exported to modules by the migration code. Again, I'm not trying to define the "forever" code here, I'm looking for something quick and unlikely to introduce bugs so that we can move forward with splitting page & folio apart.