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 2F366C47DB3 for ; Mon, 29 Jan 2024 20:19:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B08AA6B0083; Mon, 29 Jan 2024 15:19:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AB8BA6B0092; Mon, 29 Jan 2024 15:19:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9589A6B0098; Mon, 29 Jan 2024 15:19:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 83DF26B0083 for ; Mon, 29 Jan 2024 15:19:25 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4F8C5140B4B for ; Mon, 29 Jan 2024 20:19:25 +0000 (UTC) X-FDA: 81733463490.11.9F44D0C Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id ED6BA100027 for ; Mon, 29 Jan 2024 20:19:22 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fLQTzX0B; spf=none (imf14.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=1706559563; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WAigPmVNmrZ4Q7NScBbnGOHfNcKGdxLaLpMpEktixVw=; b=hDF2xFOLVy8QpwHyPc3scFz1sq0WFWMYBLHbxsZ91XPdKyXCma25UXP9YeTc2s7HNOXc8s 5Ja4oZLU5bW4GztUj0s5mGD0/EpcTo/HMi/LdXUVerPZsV30lhHJ4hdUCILkBB6eG/dZOD 8kpWDjSoJFascnMT0i/6c0rcElNVGYo= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fLQTzX0B; spf=none (imf14.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=1706559563; a=rsa-sha256; cv=none; b=qMuD9ihGsKhvSLgK3x4QEY/h84Tu07uUjqvMaxql/nQCGJgPF402IdZkl1iHQVtc2XMIG4 M7BlGLggswqpBpvl3BsthV6+B3gUVflTgojV4NYHJLwobHUKPuSQ6N6lCGoqdA72Eii6h/ WNv/pA4qXyVw6FAr9p4fWfvqi+uNovU= 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:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=WAigPmVNmrZ4Q7NScBbnGOHfNcKGdxLaLpMpEktixVw=; b=fLQTzX0B2kYvB5i93Y4XIvbGMc dm9ecb4yVk5wybSuBljWIkleLuSyQ+mMl1Dxvj7yWn21F4JhMRWxn0+9oCv7tRwP6tdD+euHOiAhC Zo1XZHkbL/FLYK49Ucm0dmV/chfpFGtcKdy51xhkmwSVtH7CFvdq2xZMg1ZF9X81K2Le1kDaWcksS E22VHU7BwhPIgw0UT7SOS6zY26Hn0G42CRc08Ions+kWCPRGnglT3bs8H63h3B91lCJOj+ehwZkJw lYJpFLjfRvYD0rIXA99z0WQkDlD+kpDM92/1lTAZC+dAJxXroKVExnN8OJfIubl/tmp9v7wjLUOE8 5Sp5KOeQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rUY63-00000007eMk-11Xv; Mon, 29 Jan 2024 20:19:11 +0000 Date: Mon, 29 Jan 2024 20:19:11 +0000 From: Matthew Wilcox To: Carlos Llamas Cc: Alice Ryhl , Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Kees Cook , Al Viro , Andrew Morton , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Suren Baghdasaryan , Arnd Bergmann , linux-mm@kvack.org, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Christian Brauner Subject: Re: [PATCH 3/3] rust: add abstraction for `struct page` Message-ID: References: <20240124-alice-mm-v1-0-d1abcec83c44@google.com> <20240124-alice-mm-v1-3-d1abcec83c44@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: ED6BA100027 X-Rspam-User: X-Stat-Signature: q6athw3j1tqfb5kgm6rzw5et3dfro1qb X-Rspamd-Server: rspam01 X-HE-Tag: 1706559562-11903 X-HE-Meta: U2FsdGVkX18yL7p+cTA55O4ajGrQNqLlB6NTlI3swgKol8zhgjHBqcFvOXbuhqumHMNOwBX/QGGRBywetRfLPduI9iJRoark0qKQjoG8QR0Wp+spYyb3OQGaSfOoUzUChaVu1Etb+fyNuyrbkslqpQlbIfJ9+75xXpK+XB5MlWI6pHZNczsMRz3Q073X7O1cg+WIj4RxCWd50+O7OGpdox4f9/UE1m5ZpsDidWnHyQMlFfcwQ83B/ddRfPdF8dPLY1QzTZkZ7eU5/i3iDZbwcmEnH0pTJiJNPF0c8B/SdXCc0j/X7rjja4MqPmJYw7nMBanSwFVAPQeOR+NMEoJ0j5EhSUo0GbFUyy2SglhLT01aBWOh1AXMDa39lic2o7Z62qWeARdTNDzFnN3Zrre5NLjgiNXLFjWkYUKeA7SrjHEi4PoziXs8AQ0YmETTf2OyCOeVh8UYicbfFZwQdOll7kQKf4nw3IFQGl75NIO6hPz2a0m+TxMCAPr5Zlq2kN4J6GC13btvXQB0JUQKn6UCV2AeDgQ5gEhxvtzjNUKwNqw2+UKh6SWxrvHNU5TJPgJmSKGiTuWjL8s/ykJPg95mRlTgsLoeN4LwF02vY5EGXFxAc73jybONgoy0ofyYRWa9vvBgkYDCF3O8FU/L//c2sMOY6SV6ugw8zZgq2FFJ2w1/k484o3r1Hsakpo9WFJTpStMOFrkWhAeiDM/5pW+TxA2weYdOdjnMLBGoAmA626UeMnognT/CqJ4a4L3E5NBIp8WJ8D14aAWCTHoNVsamU6d/KVXqlCLdBMF9MhKeXY6K5TOKadRFdDS7BHXXuvw9/xwEBqZ1xZhmiU/yoVy+3KHPQZwHFDadacPXMU6ooJ44+w/2txOq8bHV+grIJXmHefqZfKQ82TwAN4GXt57cX0uQmvDldg3/MUh+nnH+IXrBN69Ir0+N6+Vs9ITDsid+aX6CDTdwGeSDgz9m8Hu fVM/qjIb ntdA1zaEMnbQ7imq/dFpDmEmrPb6ixdLHZYyLwg7Yh0uJ7MjlKUza2p4VtVtVO9AmmlA8/gf0IDuumm5nblEqFqJ/mA44NQDIg0m96p1jESaUKIO+r3aL07s4lt8WVv9w24ZGH5laE/OBoVlGeJ4ceKMFNieoLU3f9pj01O5LV0L+5uTfVUSl6D0BCZo/FxXwL/IGvi0UPJzYq5NQ80v+yP65sw== 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, Jan 29, 2024 at 06:56:58PM +0000, Carlos Llamas wrote: > On Mon, Jan 29, 2024 at 05:59:53PM +0000, Matthew Wilcox wrote: > > On Wed, Jan 24, 2024 at 11:20:23AM +0000, Alice Ryhl wrote: > > > This patch only adds support for pages of order zero, as that is all > > > Rust Binder needs. However, it is written to make it easy to add support > > > for higher-order pages in the future. To do that, you would add a const > > > generic parameter to `Page` that specifies the order. Most of the > > > methods do not need to be adjusted, as the logic for dealing with > > > mapping multiple pages at once can be isolated to just the > > > `with_pointer_into_page` method. Finally, the struct can be renamed to > > > `Pages`, and the type alias `Page = Pages<0>` can be introduced. > > > > This description concerns me because it reads like you're not keeping > > up with the current thinking in MM about what pages are and how we're > > improving the type hierarchy. As in, we're creating one instead of > > allowing the current mish-mash of absolutely everything to continue. > > > > Are you the right person to ask about the operations that Binder does > > with a page so we can figure out where it fits in the type hierarchy? > > I would guess you are suggesting a transition to folios here? I don't I don't think folios are the right type to use. Folios are for files and anonymous memory; things which are managed on the LRU, have refcounts and mapcounts, can be found with an rmap, need private data, belong to memory control groups, belong to either an inode or an anon_vma, and so on. It's _possible_ that Binder fits this use case well enough, but my guess is that it needs its own type, or maybe it's the initial example of a different type from folios (right now we have three types: folios, slabs and ptdescs, but more are on their way). > The only concern I have is that we've implemented a binder LRU-shrinker > mechanism. We add the unused pages to our freelist and give them back to > the system on demand. However, if a new transaction requests the unused > page before it gets reclaimed it is simply removed from this freelist. > This is convenient as we avoid taking the mmap sem during this process. > I don't know how this mechanism would look with folios though? This doesn't seem like too much of a problem. The key thing is that with memdescs, you get to define your own data type of whatever size makes sense for you. Until then you're limited to what we can fit into a struct page (and we need to be careful not to step on stuff that other people look at like the refcount).