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 D2177C47DB3 for ; Mon, 29 Jan 2024 18:57:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43C4E6B0080; Mon, 29 Jan 2024 13:57:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C72B6B0087; Mon, 29 Jan 2024 13:57:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 23E746B0099; Mon, 29 Jan 2024 13:57:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0ECFB6B0080 for ; Mon, 29 Jan 2024 13:57:07 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 573554066F for ; Mon, 29 Jan 2024 18:57:06 +0000 (UTC) X-FDA: 81733256052.07.31CD962 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by imf14.hostedemail.com (Postfix) with ESMTP id BDEF8100006 for ; Mon, 29 Jan 2024 18:57:04 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="3NlbTRy/"; spf=pass (imf14.hostedemail.com: domain of cmllamas@google.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=cmllamas@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706554624; 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=xb1se6XYnX/io6AeNksDGE+479xc8/XFvlgChDKCPRM=; b=xPaXs/segNYcFbgHKjXp4KD+CdgAtDy6V+7eaT6/N4+tzx09ppKrH2fLWBypWa+73uT50k LBB0rkBsO9J+nmN99Srr8qkLmePA/pl/fekFnrY7r6nBEzRIMNTZiyCBQ5UZUWNPbFZg7g fxvOWlLlEziUG2UAhO3g/Ruzpp5KtBk= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="3NlbTRy/"; spf=pass (imf14.hostedemail.com: domain of cmllamas@google.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=cmllamas@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706554624; a=rsa-sha256; cv=none; b=MLw4Vk/MFZI4WA/twohmTX3AD7ItexISn0eo75leFTMYgU7KYpwMTtNS3igfMYCe2hsl5X P2IhysKf11S3APBuF6faiblOP5K1tQZtmSKntlTKAj6Awya03v7XvAN36Asjp6c9H90LhA B+an9rWcs0vX2+fmAVYeYjYUAVszIeM= Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-1d8cea8bb3bso6472765ad.2 for ; Mon, 29 Jan 2024 10:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706554623; x=1707159423; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=xb1se6XYnX/io6AeNksDGE+479xc8/XFvlgChDKCPRM=; b=3NlbTRy/acVVI77KD1wPhw+VUO1nG2NTe3/fgpjH2jGUZiZs+XSOqQC74VaPStsr5g lpammMwEYEBUCdBag8vSK8KkBzWncGoNB9Gn4bpji8uLE/lhLL1AHnaloPxDW+eJwIO3 TuYZpZ5c18nvnBAvylEFmaUJujTwCEPbf5505cnojdRoqKuipBQF748/KpuEe0+aSVvl Ab+n611yNlbnWsT5szwtNGdphon+5Z8YPdFvGTRSWt3pDjg6UlBNkZPOHLWTilxS7sGg KlSQserhX56BEuMa/B4cbkRnyL1/TmBVRHBSH4i5mpfw0KVyv99kr4biOzLJTO51U4aK dDYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706554623; x=1707159423; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xb1se6XYnX/io6AeNksDGE+479xc8/XFvlgChDKCPRM=; b=lCspbky/Yx8T4QOLipYULjVOnnsRwnoayi82wdQWwUtW55ocAVYIYQjfxQ/QBz7MIW VyrRaJnoRiOnTYDQTCgUXEhUXkwfenBAuJauAKxEWJdbew/x5/YHolz4BYIOd+f7xKiO vjyaztzP2L+FAuZdCDHujU+gfT52vA+FsY8QdRiOImIF1MKy960MNQenUqDgspngZfWK 0wsWzk1Zu7BmCJ07/yMdv/lUc+/qG/RB+nAEbIuu2NkZim2aXuPaOBpTIfRx1tl1K989 GonSMm+yF/2iOJxUL+yn/K6/yBJafSbSH8pQs2bQlT2y67VDsYwE33Q9z+61eU8LJbXH Qa/A== X-Gm-Message-State: AOJu0Yy/utvzzlterWnEp8qGC8CFOp8t7CZbtpS/JFTvjhUY5Hvys6cA 3gU8xP4RI7YuR7KHaWVgvTXlS1jhv9OKPlQhzHvGy8bU135oZ/p4tXIcwib4rw== X-Google-Smtp-Source: AGHT+IHDPJf6Cs1/rFQndlGrqInaTjASmhMPFG6hMvQzgDeukzrXVXyHNQnpPCxBHxyveq9IHhfIWg== X-Received: by 2002:a17:902:d2ca:b0:1d8:faf7:7f77 with SMTP id n10-20020a170902d2ca00b001d8faf77f77mr1125402plc.24.1706554623320; Mon, 29 Jan 2024 10:57:03 -0800 (PST) Received: from google.com (152.33.83.34.bc.googleusercontent.com. [34.83.33.152]) by smtp.gmail.com with ESMTPSA id c6-20020a170902724600b001d8aadaa7easm4827584pll.96.2024.01.29.10.57.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 10:57:02 -0800 (PST) Date: Mon, 29 Jan 2024 18:56:58 +0000 From: Carlos Llamas To: Matthew Wilcox 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: BDEF8100006 X-Rspam-User: X-Stat-Signature: diggj45foen9jqa1iezfgfpjszeaf684 X-Rspamd-Server: rspam01 X-HE-Tag: 1706554624-483270 X-HE-Meta: U2FsdGVkX1+Fg0RmtFIUzkc6YZB+UHtQjrHSrIB0mK/5IqOq2eoKWGmf0aNdFdfqgFFny/FyFgbLLwOcu8WMPsBpNVLn9D/WDxMp7UPbYkST/fUt3rbxcTvCAqWqrSTsqtWDvQAikdq47kxUehZS1WEZg8nW5kyVw2dSQfBOcgvpofBC8O0+mkMB27XvEGoL18H2IuDJihdAuCXEj4gslW+MaNNLuwwrz6ccQqi8OfS8ixTBkeYN4C0euyjieoEIW92kpycCPwg8/vsMA5C6PuaGznysuItJXyy+d/ocjGqfxofakuOpzjNCsGq0YGJ6+2IJJIhcTX5BuqHi632r40f8QWdzmA1zfe1HsRYrhIRrDaMVRoglMmurwokpjMKj5wVQNnFV2YNcQ02wJpQg3ZPmZ8gY0JJzHutsPjoS3NqXGrUZkqVkx0+0aLTrSW4o1FmKhwzUh9PeICG/SLbkFOo+MD/oiwvVMfD2yXKSderkL67eHck+VHaWuFuGJcW1k6eNsQRUXNzMVLZ0OLEz6JtvsqLHVeD37yHq0AGihOERZ69uGhLQKP4cBHUTsrj0+JDxdCZx/8lpeCDcn0jQYguRaMKsJTmdrh713grcHBW+yPwCL9H2ZxcRA6PM87xB0g2s9gb4tdqYumKbv3mVfL32K67B0d48vkRJRofjteUHYJLct76xxLNJ6GImiftelPHbxFnWGn0qB+x44DXOKGsj7307FCgtH+kcrx/Rzxqb4f90JGQINAgXfeHKxehXTyCCoQ6tz7cedoZXNB0cYRReYZ0ENaamRQInESGkGeH04Wbi4DRve3mN4Oetzvmurzu/D/uylG91zeruaX/rHKk1A6sMSTfqoMZq+Ht6McyZynw4FAj3K7BW1JHT4eYB/9U8c9BngEj9PogYepEyOA8U3w11Gahl0A31G12qeKfIhESEZ0CWpZhTsMliTJuHJHV4zHGbzpZ6Y4dv3L6 nI20aYlK LOfrJ+D/MkcnmIyJ2ZUhtqC/EGaKjMUj/msueReoD8tHs8p4YWYkWkB+lVIyFWXI3uPm52lkfqtu4ioAoLpT4/jHJ9mo1pNZCxCuGKzfKYYW0gVrirPLQwC5K2SLhAbzev8vB5TJUopIfG2ltBj7Jq4kZeA== 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 05:59:53PM +0000, Matthew Wilcox wrote: > On Wed, Jan 24, 2024 at 11:20:23AM +0000, Alice Ryhl wrote: > > Adds a new struct called `Page` that wraps a pointer to `struct page`. > > This struct is assumed to hold ownership over the page, so that Rust > > code can allocate and manage pages directly. > > OK ... > > > 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 think there is anything in binder that would impede such a change. The core idea behind binder IPC is to skip kernel buffering and perform instead a "copy-once" of messages across users memory. In theory this seems efficient but I haven't seen any data proving so. So take that with a grain of salt. The size of these binder messages is not limited per se and can trigger the allocation of multiple pages. However, in reality the vast majority of transactions are under 1K payload. FWICT, it seems reasonable to switch over to folios. 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? -- Carlos Llamas