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 C2D19D711CB for ; Wed, 20 Nov 2024 17:02:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D55786B0088; Wed, 20 Nov 2024 12:02:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CDE226B0092; Wed, 20 Nov 2024 12:02:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B57376B009C; Wed, 20 Nov 2024 12:02:28 -0500 (EST) 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 93DF96B0088 for ; Wed, 20 Nov 2024 12:02:28 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 3FC9E1609FB for ; Wed, 20 Nov 2024 17:02:28 +0000 (UTC) X-FDA: 82807090464.22.5D7C724 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf11.hostedemail.com (Postfix) with ESMTP id 5E1774000D for ; Wed, 20 Nov 2024 17:01:21 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=QPD4+th3; dmarc=none; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732121961; a=rsa-sha256; cv=none; b=vk2kJm+rsPJj4ZH1kILwrhTdrrC9ZfoDz03iGvnkc81iAvk3YKHWnriR2WUQ284kaJrJXS FDLKHi1ZpfxRpDYn84pYBC0NCb8vTtL0V+OPIf6K74+g2BLFdF2Onl65Fkl0SSTb21HzGa sFdJEXBWLTtL2NsbdS1chBm/AckXQ+s= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=QPD4+th3; dmarc=none; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732121961; 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=zYAMajNMtocU0CffdSuW1w5BhKd5VeQZLt1Tp6ZRjHg=; b=mS6OfPPvvZac/NzKE1kEtTgVOjWDWtiLHC6m1aK93O2iZsiHZaG+lmrnYtKc132F6E77zQ IoFCXQu/C9mnkAT/vkmzC9T6TqBSDCjV1BLBfCdJzDLWTWtanzrcdlR6mbb2l0jYGC0d+T Y6aWxVzISX9dDwE/uljGIIeI5Jvm9ZU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=zYAMajNMtocU0CffdSuW1w5BhKd5VeQZLt1Tp6ZRjHg=; b=QPD4+th3XvJ/Zv02g13zjI3s5V L8VxOyPaPSlG1Sbd2k/rpk3aVcZ7glBSuv4nzP4vmqtVwBsm1VQEZqvTNZKOwRElx+Lv5MMyuo4Jn IxEUComnwuqO3SPte5+1HPPMBwlqAnCpD3P+tD7IKXRjW9Oa/84gVu3NAX6t1A/1MbMoSY5gO0ZFi OQMSurxwYvDAQXIn3uji2saB+6Dwk3AbBI/dUPkUFCy2Y8ZeFZV2g0dbDztpv++HDWqu4dvxmVfcQ 7+pz8lyevbXNUba4X0fPaGbw7AI2QA6z/UJsI+2ytco/sMFMGOzu+MUI/JMpdxNmijCuV9Xu3Sg6z LoKpCrEA==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tDo5n-00000005THA-07M3; Wed, 20 Nov 2024 17:02:15 +0000 Date: Wed, 20 Nov 2024 17:02:14 +0000 From: Matthew Wilcox To: Boqun Feng Cc: Alice Ryhl , Abdiel Janulgue , rust-for-linux@vger.kernel.org, Miguel Ojeda , Alex Gaynor , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= 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 Subject: Re: [PATCH v3 0/2] rust: page: Add support for existing struct page mappings Message-ID: References: <20241119112408.779243-1-abdiel.janulgue@gmail.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: stzbfkrgyzjs14g9utezfz9ckoc93rdo X-Rspamd-Queue-Id: 5E1774000D X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1732122081-795354 X-HE-Meta: U2FsdGVkX1+FQPJG3Nx0OWQvH3q/LjqJz421xUizjIVdRJK0daZos7UhPeOiD8imW3eLoNC1qp0RieMb+fpRqFDbUCDdvUmRtNDpfTIagOPjaJ7rN9lcFeDypP5EpYFXfv+tH0/0eyAFuSur3cn9PgAPiQQ69C8dKGYmQCX2RsVpahtQ+XESiKFf3tXbJp1aEauhmmqA5FEeeGJnFmTuoVSu4KPxFTddC8O7QXYYQMOM3u6F2x0n1/Fov9g7JrDFvsXXlN8nA4zj8suljNy9YFg2n/GvRA5sNn8qoEVEuKC1sX/zfEsakpGq8fqUr9ANXq7Df7C1OTQ90FlO6KFwfUxEbIpFX88mL24AMLo1a7bJG8L6F1YV+DizdRaK2YuOoxu65e0tA8FiQRp3C6tYSK2NrFiLS14bUDEB/E2l8XXoBQs0kDkiyt6vlu95XjSy7BDLhCaXEpEKsS4HrRimbSZoIhskxUbP9NAVSd7C1oMrvnZwi8ti2wckwT9P0LGtcsbIygmEvmGdcnVS3NVj1Wyzpb1JJWmBTs3Ca+Eu0PbDulGwV0xaRB7q44qCPdxz9BfG29Hpvb73vrxq6OwNnLaiTKStyZ09kV8fIguZ8YnWVuaI+XRM10mfhCWH1Ky8ZUVWHd5AtOlmlREHNe0BYnUJ6juS3jTSsilF1x9RjT0y/99j5D7PYKtiKpCC7LdqNwA01XqyI/rRFgcKKNiUNXJ0+DsRyGOXVoIeqDj9TxiBkGt8EmBQaCEXGzhsaMuWlISMnS98Yj2H8FBFBMg9DbNiWxY+ADKPcyQb+YsGO+IT6f7SEpaEHfz/jfBMnF/y8htwhaqAX+VpGtG3OzX9oNWV+qlPx2vTXj6uRj2+ilbBk5myzk4paX3TLIB8bKO1QqwgnSlYTdsD506vu8ybWmuArJeh1oY5qK6fSdDDuwxQ0uk8fnpjao18t4mVhI3vgEtNX8T223CGiac0JpO z0R6jqIq sRSEdtJO4KxeyNseCk6BpTGX29yc2AQIbYRT6+I38vnZt0s1S3BmFItq6NwIOMjo9Ah4d1zSLFU4eCAKO3Ft135WAxKzgrifUuHzNsOdsP43Ok9ApsRdxriDRwHaA1SqUdYroEC8vSblVnqLVDjB4h3Gj2jQS16j8YtPk0LCIfGnUUAc+wkUXo3mt1EuS5NbGswR2YZf/8eDgdHvRt1KUkB5ASfio77y+A+1X3yQSwhgmRMJCyVKi7H27qs0x6uzertOfOxDZlNNVPzex2xUPjVeVyLWs1edO3QXT2xCjaazYpdRcqnhGwVp1XIeXrwd+NjDw0LWPmIRvRIHeGyLeZ89Wy5aTL9FWLdLuCT1KMEVVQYoNXGrwGoNUbCN1xrj9o6m5dJluOTXxlCw= 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 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 AM Matthew Wilcox wrote: > > > > > > On Tue, Nov 19, 2024 at 01:24:01PM +0200, Abdiel Janulgue wrote: > > > > This series aims to add support for pages that are not constructed by an > > > > instance of the rust Page abstraction, for example those returned by > > > > vmalloc_to_page() or virt_to_page(). > > > > > > > > Changes sinve v3: > > > > - Use the struct page's reference count to decide when to free 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 of a page > > > will be controlled by the memdesc that it belongs to. Some of those > > > memdescs will have refcounts, but others will not. > > > > > One question: will the page that doesn't have refcounts has an exclusive > owner? I.e. there is one owner that's responsible to free the page 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 example), 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 would 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 always defined by a higher level object. > > > 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 want 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 previous > > version did not expose it. This came out of the advice to use put_page > > over free_page. Does this mean that we should switch to put_page but > > not use get_page? Did I advise using put_page() over free_page()? I hope I didn't say 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 maybe it does need a refcount. > 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 with 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.