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 7A807D75BDD for ; Thu, 21 Nov 2024 09:19:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B23C46B007B; Thu, 21 Nov 2024 04:19:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AD33E6B0082; Thu, 21 Nov 2024 04:19:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C22D6B0083; Thu, 21 Nov 2024 04:19:20 -0500 (EST) 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 7DAE86B007B for ; Thu, 21 Nov 2024 04:19:20 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 00183160ADA for ; Thu, 21 Nov 2024 09:19:19 +0000 (UTC) X-FDA: 82809552714.11.ABB9C7E Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by imf24.hostedemail.com (Postfix) with ESMTP id 52C8518001A for ; Thu, 21 Nov 2024 09:19:11 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=YSM6Ue90; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.54 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732180666; 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=xWnOXVmJjdtAdRRd+DO279ItwAu/YGVGHFICEKvN/5c=; b=1qHpFyheNwgJc/PD6Iiu9/fzdZ/aRCH7Dk5PYXRATzUkdiPRU+1hzkabfi2O56cUsc7h9O 8E667t3EoAJ6POuVx/uQuAcgRZ8peELjqFGr2e3WWPmDKeEim8Xfjek727NFoy7GEmcPb0 BrE4sFJzW7JbDTmIVhhIUtSNMncp2lU= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=YSM6Ue90; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.54 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732180666; a=rsa-sha256; cv=none; b=35Um47hkL44R9mTZtRzmJ8XP+WC7UQjGF4Ohz0vc5c5V6fP5m/vsbeSz6XkifaCK5zd6hA 7WQY5eAbwrUM1buianuNlOZmmu3yxK4pS506tsg+/0cnK3BcjU8XaAAHAlgsjJXJb3Zq9L S2b5Xq5DEIBLQenYyefQg8U6I7f0Hmc= Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-3825c05cc90so205679f8f.1 for ; Thu, 21 Nov 2024 01:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732180756; x=1732785556; 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=xWnOXVmJjdtAdRRd+DO279ItwAu/YGVGHFICEKvN/5c=; b=YSM6Ue900Ndwwxy5/8Chry9o/OIfwMBT9DCZde1EYWfcqDNMMZ9ShQaDhUcgjvEaSQ 8sCSvVvbYE4repc7A9+aeVqfTWsX0A04Tf54g5a6XRPwzPUtOdTBgsMG1Ms0QxU/vXBF t5MUGIP7J3iLY0huoi3YYEtKLxKjgbYnCoMFVsRK2UFfGt1FaTmDm9Bogt12d42gAp+4 nhNe5wuBedDvaRZRcpGpkDsNkGGKZZrH+h5a9YRtMMwVG9FIO8gRJ5dUxJoWlwgaMG6f 6cQRpbyYNuLmvYsCO0dH9yDj4MGq8ExgUWaZZRFA6BK7u6R4nW3n+r1uiSfu6S0XTrru 1N6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732180756; x=1732785556; 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=xWnOXVmJjdtAdRRd+DO279ItwAu/YGVGHFICEKvN/5c=; b=rFeogOApSZB7hjhMTOcFsVx3/cYa92HbJgc9xgyHIwOM637tB4D8OKw1oaGubHbYW2 o47iSqAQVM9JLR4mE1fWlmJOKpqLXavxPQPxzpNLIf5rzMofzUij/fOJo79vHWna80dv YFsCj8sxCZq5CVI3js91qU1EjrHTlH6DDgL8UKr5xs9blpVCHzdjnD1lBpKp0+d7lsnC dTdslo6lUvaXLUgXl2lwEERDIAZPKtw2H/ru8sF/HX8vrFvrjg2Smz4+q+VmriogBLSE Kw/BMOG8CZr+4m6B2dqGY9LIva8x7qqvhCIUTXZp5aejNbm4gZ6qcvpeb85EwfTVZKyf XwAQ== X-Forwarded-Encrypted: i=1; AJvYcCWWP/8EYYjxg4Dl2ZI7H8aZAcc2Toca6iDcXks8FFjxdU2BtOpyPFRPn04bwLygSvzu8eLuxtp+ag==@kvack.org X-Gm-Message-State: AOJu0YyVS0O64NNlYKG99B+E+xwlGHM2SGwt8ZW+0Eaiw30tf06GUN1M suA+IMeDUwRoZ841QUzeplDkKPPX0bqs5XgnodioMTqm0XQgyx/XOhdahk/qAyv64gSOHzq+gmq LvjssBp0zqSmLJ/4hiHGerOTnZApJtYys77Lx X-Google-Smtp-Source: AGHT+IGzd0rr0615sN3eclq4wC/2Zg2K1p0YgkP6NPZCIYdaXry1agGbeX7Pz8cePL2TH0N3TNUhjrZNX0mcB4nCfWA= X-Received: by 2002:a05:6000:2105:b0:381:f08b:71a4 with SMTP id ffacd0b85a97d-38254b162f8mr3581284f8f.45.1732180756342; Thu, 21 Nov 2024 01:19:16 -0800 (PST) MIME-Version: 1.0 References: <20241119112408.779243-1-abdiel.janulgue@gmail.com> <98a46b27-c4bb-4540-8f75-f176c3f2fae1@gmail.com> In-Reply-To: From: Alice Ryhl Date: Thu, 21 Nov 2024 10:19:04 +0100 Message-ID: Subject: Re: [PATCH v3 0/2] rust: page: Add support for existing struct page mappings To: Boqun Feng Cc: Abdiel Janulgue , Matthew Wilcox , rust-for-linux@vger.kernel.org, Miguel Ojeda , Alex Gaynor , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Wedson Almeida Filho , Valentin Obst , open list , Andrew Morton , "open list:MEMORY MANAGEMENT" , airlied@redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 52C8518001A X-Stat-Signature: xooiwrxb7hg4kezf1ngxwaje4h17izo4 X-HE-Tag: 1732180751-381934 X-HE-Meta: U2FsdGVkX18S9aonlhC1V6A+HRvlXMCAht2w4/rY+XlDRCUtJci8452H2VEYcDykrlM18rPw7SGjDH1k8kZ2Sb5f5TOFAsrMPMNnKtZ7V4BkMy4m4JFOt4xPSngq6vPFLJNx8UHmmkchibDFyz3s7Sbn1iQIBE2tB9JTYBGZsGHKpIEi6ok6PNV+3zAAu45Qs6soMYHLepYZF1R7uR/xm4dNHMZppM6vdsuRm0LprkJYmdsOj/nhpPNOSL9A3+dV40JrKfGlyL9P4wwp92syJEaxn6U/tzKD8V4soEA5WqDEJt2HjlE92fnr6TR2WiwAfGhzHrMgG2fjLm2LQ76jjqpLZJ1pev1IvB2eyqgnqLXRkceQvHfXKFvaSXf41hI10XshHkFidPkKSR77fTrLhpnEgc9M4aRuhX1j2d6JnUrA+r/+Ket+PQPDqd23a3xcxgpRLp1zmlfQjRMZoju8lk+QT69ecUl3LgC8iG/rksAI4hSHP4Jg2nzOPZjAb1ar5PdoO+pBYeekPFo0pGBF9B0exckbmFgz66OxQWBHQFkGrnE7GHB8I7zEd2jqqu6r3tmVBoYSCBHYb3IPyTA1C/onM4KzGlYr4EYAEx1WK5dug6HPSSLRo5RK3p2rJwI0mOl9dLcTKgDZsqlZpAcvZgbmy89OBrBwIKA/mu7r50/5WwuJBLYKSW0WK+TOmKHMZMjtnlxl7hzJFuPUGYYqSc1h4CDUifJvt6TYkvWN2dDgQ5E+XHokRv3MzFAWhl4oLxi6vU+g7m2/QT9r/eeZoGrna1MfOfrUGDG/dql90mVs5SJHHXmWhtVXB8byo7tk9GXXo/QORICuRzDmfdHU2y63PwSr+ZwpMIxpxY+Pi7qEijLPTsn4TmdlFmZsulKbi4fagXUGsyeisGOrE/SbWtSK/7KwcQNxU9JAayAz7OSMIc4C2YkNah3w+AOE3Y4lKk5Nx+GA8mfDOKWST+r MQWUhXSX G+i1CTDZAvQTSgkhuIl+HmN/HHD56MnKk8vwWGeNdmvWS2mFBRuLw4lL5EueWU5qD1/XnCewUroIMjoylBeSnKf7Jd2tsoOWPtUV++3o4IJAwtBkkvAl8ZxbAtFnBKHwCtXB/gyYDPPVHmmqwAaPlQugU8T3n9d5m57ZhqKgOgIi+Xzex5zrir6Tphc8pgGp/Pvwm4y0IgXmUNRMnN//Pnmx5iDCNQ2X5ZHHl6zaReIujLMxzEnj+BtWajo6lB4Y3ppfBdg+9t9ujt2MGrnHYVHTYKJ/PtrxDXFYrQzofBKOAeA8eywdnBbRrbWrmm9U6sg16EH4BtssE6JCvCPRZBQmWFb75FCDpYoUP 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 Thu, Nov 21, 2024 at 1:24=E2=80=AFAM Boqun Feng w= rote: > > On Thu, Nov 21, 2024 at 12:56:38AM +0200, Abdiel Janulgue wrote: > > On 20/11/2024 19:25, Boqun Feng wrote: > > > On Wed, Nov 20, 2024 at 05:02:14PM +0000, Matthew Wilcox wrote: > > > > On Wed, Nov 20, 2024 at 08:20:16AM -0800, Boqun Feng wrote: > > > > > On Wed, Nov 20, 2024 at 10:10:44AM +0100, Alice Ryhl wrote: > > > > > > On Wed, Nov 20, 2024 at 5:57=E2=80=AFAM Matthew Wilcox wrote: > > > > > > > > > > > > > > On Tue, Nov 19, 2024 at 01:24:01PM +0200, Abdiel Janulgue wro= te: > > > > > > > > This series aims to add support for pages that are not cons= tructed by an > > > > > > > > instance of the rust Page abstraction, for example those re= turned by > > > > > > > > vmalloc_to_page() or virt_to_page(). > > > > > > > > > > > > > > > > Changes sinve v3: > > > > > > > > - Use the struct page's reference count to decide when to f= ree the > > > > > > > > allocation (Alice Ryhl, Boqun Feng). > > > > > > > > > > > > > > Bleh, this is going to be "exciting". We're in the middle of= a multi-year > > > > > > > project to remove refcounts from struct page. The lifetime o= f a page > > > > > > > will be controlled by the memdesc that it belongs to. Some o= f those > > > > > > > memdescs will have refcounts, but others will not. > > > > > > > > > > > > > > > > > One question: will the page that doesn't have refcounts has an ex= clusive > > > > > owner? I.e. there is one owner that's responsible to free the pag= e and > > > > > make sure other references to the page get properly invalidated (= maybe > > > > > via RCU?) > > > > > > > > It's up to the owner of the page how they want to manage freeing it= . > > > > They can use a refcount (folios will still have a refcount, for exa= mple), > > > > or they can know when there are no more users of the page (eg slab = knows > > > > when all objects in a slab are freed). RCU is a possibility, but w= ould > > > > be quite unusual I would think. The model I'm looking for here is = that > > > > 'page' is too low-level an object to have its own lifecycle; it's a= lways > > > > defined by a higher level object. > > > > > > > > > > Ok, that makes sense. That's actually aligned with the direction we a= re > > > heading in this patch: make `struct Page` itself independent on how t= he > > > lifetime is maintained. Conceptually, say we can define folio in pure > > > Rust, it could be: > > > > > > struct Folio { > > > head: Page, /* or a union of page */ > > > ... > > > } > > > > > > and we can `impl AlwaysRefcounted for Folio`, which implies there is = a > > > refcount inside. And we can also have a `Foo` being: > > > > > > struct Foo { > > > inner: Page, > > > } > > > > > > which doesn't implement `AlwaysRefcounted`, and that suggests a > > > different way the page lifetime will be maintained. > > > > > > > > > > We don't have a fully formed destination yet, so I can't give= you a > > > > > > > definite answer to a lot of questions. Obviously I don't wan= t to hold > > > > > > > up the Rust project in any way, but I need to know that what = we're trying > > > > > > > to do will be expressible in Rust. > > > > > > > > > > > > > > Can we avoid referring to a page's refcount? > > > > > > > > > > > > I don't think this patch needs the refcount at all, and the pre= vious > > > > > > version did not expose it. This came out of the advice to use p= ut_page > > > > > > over free_page. Does this mean that we should switch to put_pag= e but > > > > > > not use get_page? > > > > > > > > Did I advise using put_page() over free_page()? I hope I didn't sa= y > > > > > > We have some off-list discussion about free_page() doesn't always fre= e > > > the page if you could remember. > > > > > > > that. I don't see a reason why binder needs to refcount its pages = (nor > > > > use a mapcount on them), but I don't fully understand binder so may= be > > > > it does need a refcount. > > > > > > I don't think binder needs it either, but I think Abdiel here has a > > > different usage than binder. > > > > > > > > > > > > I think the point is finding the exact lifetime model for pages, = if it's > > > > > not a simple refcounting, then what it is? Besides, we can still > > > > > represent refcounting pages with `struct Page` and other pages wi= th a > > > > > different type name. So as far as I can see, this patch is OK for= now. > > > > > > > > I don't want Page to have a refcount. If you need something with a > > > > refcount, it needs to be called something else. > > > > > > So if I understand correctly, what Abdiel needs here is a way to conv= ert > > > a virtual address to the corresponding page, would it make sense to j= ust > > > use folio in this case? Abdiel, what's the operation you are going to > > > call on the page you get? > > > > Yes that's basically it. The goal here is represent those existing stru= ct > > page within this rust Page abstraction but at the same time to avoid ta= king > > over its ownership. > > > > Boqun, Alice, should we reconsider Ownable and Owned trait again? :) > > > > Could you use folio in your case? If so, we can provide a simple binding > for folio which should be `AlwaysRefcounted`, and re-investigate how > page should be wrapped. Well, regardless of that, I do think it sounds like Owned / Ownable is the right way forward for Page. Alice