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 42170C05027 for ; Thu, 2 Feb 2023 21:49:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64C106B0071; Thu, 2 Feb 2023 16:49:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FC006B0073; Thu, 2 Feb 2023 16:49:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49CCA6B0074; Thu, 2 Feb 2023 16:49:06 -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 3595B6B0071 for ; Thu, 2 Feb 2023 16:49:06 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 054EEC1025 for ; Thu, 2 Feb 2023 21:49:05 +0000 (UTC) X-FDA: 80423692692.22.30ED2AA Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by imf22.hostedemail.com (Postfix) with ESMTP id F04C0C0004 for ; Thu, 2 Feb 2023 21:49:03 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=shutemov.name header.s=fm2 header.b=V5sNeS7V; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=J4noaTFI; spf=pass (imf22.hostedemail.com: domain of kirill@shutemov.name designates 66.111.4.25 as permitted sender) smtp.mailfrom=kirill@shutemov.name; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675374544; 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=5tumJ1v1RegHftfj9mx4MPAJ6ECH6Mai+PtUbbz63BE=; b=U9652SFPrS6TmeBnS4MNTRkuTh646nhg2salPIZ+jJifYBgPhwFwMUbGRUxBHRzDs91taB 31Oh+jI4SSIugjb3QhtrRD2z5ItCE0ElrAC9Ok5/cRtIO9dEvQpkNPvfjFvj7RZTEvDN1+ Qv8yNT2JlZHSSmiygfXAvdy5jFlNMLU= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=shutemov.name header.s=fm2 header.b=V5sNeS7V; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=J4noaTFI; spf=pass (imf22.hostedemail.com: domain of kirill@shutemov.name designates 66.111.4.25 as permitted sender) smtp.mailfrom=kirill@shutemov.name; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675374544; a=rsa-sha256; cv=none; b=M30zPW143qropIRGlSwoWd+HuxmIOSyUSimAyuFjYmjb1U4wE41BSJjjPyTjOtNDhaw0c3 UyTRqmMbpMmeslzQle6iY17Xyo27ruTg9YGoXOTpTZ1HL7s1D6+bzh6yGU2yJWJ218KS6I F9fTRGE+ifquNw28eX37A2eBjARSS8M= Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4DDBF5C00C9; Thu, 2 Feb 2023 16:49:03 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 02 Feb 2023 16:49:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1675374543; x=1675460943; bh=5t umJ1v1RegHftfj9mx4MPAJ6ECH6Mai+PtUbbz63BE=; b=V5sNeS7VK8NmBgS4on GkvUlLlfqxKz9vrPbjkeQPbvXI5XbUVF2m4dkcjz+zyyxb1OkdD3NEe7Bn4myCdc 4qXUqmGuZf/IrtUBAMgGaxrN6Yj0Hh+wOF0du8Vw+Vos115sEjlMYHgd30mXrUoa PI8zI2MPsGV2Ngkulk69R4BXbGSeisKCTfYih/3nOvKzIq05vNIAzUdWTeBnsVIc A79lH3V0K0AEyGLcWN5DtGPDLf01rjKln+TwxDC/yAKgqdQyrCeXMsqAqXGl9mS9 1GVX32KWDHSrf0T94tix5ro7rHJ9t7CVKUXCbNJ0jCSBo3w8dqy7sksQ4wR4luRn Qmfw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1675374543; x=1675460943; bh=5tumJ1v1RegHftfj9mx4MPAJ6ECH 6Mai+PtUbbz63BE=; b=J4noaTFIDMU8BCO9APXDYDJv31z2zllwBcbnZ/4n+UDK 9s8K+aKozm54zmvwcvYS5NqdgGwdsDDt7e/inEwe+9pC93AAjI3PqHbnQ21ohDN7 Q6rDAcKJ1WKC1yLr3jULKIMnuEupBMEg4njY56SE6iQbsrpZc3Xqmx+Okme1G0a3 YCrZwycUxkW9AfSJprRcpd5/D8B43NtKqmexbfvH7kEKR1glJbr4JHJ9wLbfAR+q +c6ho7YKfpMZlLoVKt80Q54nrB+CBZBEBVB36m//icBGthmZoQAWxrpuODXinMk2 gFqO38q9zP1F0jI6NVapV0TUm/Ra7V6zYf1y6uYF4g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefkedgudehtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehttddttddttddvnecuhfhrohhmpedfmfhi rhhilhhlucetrdcuufhhuhhtvghmohhvfdcuoehkihhrihhllhesshhhuhhtvghmohhvrd hnrghmvgeqnecuggftrfgrthhtvghrnheplefghfefteelhfevffelveffgfetffefleef udduhfejudetgefgieehfeetheejnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehkihhrihhl lhesshhhuhhtvghmohhvrdhnrghmvg X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 2 Feb 2023 16:49:02 -0500 (EST) Received: by box.shutemov.name (Postfix, from userid 1000) id 049AC10E387; Fri, 3 Feb 2023 00:48:59 +0300 (+03) Date: Fri, 3 Feb 2023 00:48:58 +0300 From: "Kirill A. Shutemov" To: Matthew Wilcox Cc: linux-arch@vger.kernel.org, Yin Fengwei , linux-mm@kvack.org Subject: Re: API for setting multiple PTEs at once Message-ID: <20230202214858.btrzrcevzxjfk6wg@box.shutemov.name> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: F04C0C0004 X-Stat-Signature: 9b9jwgujkm355kamxj8zhg6uwuonbja9 X-Rspam-User: X-HE-Tag: 1675374543-558828 X-HE-Meta: U2FsdGVkX1/wCo4G9CfAC32TCAHxP1XksVBgxnN/dBx9DLjfM6X2ppcvMFFp20ofCmADd8SAdyrzEH3E4CcDSnpWKUgmK98Xr3Lcciq04XRBjGBSlkY0QyeWhr9WnkeYfumrljY6J3c2YflaNwnrhtly6lMMfXr7JF3GCj9gWHFhM9joeyUZA5uCeiu6dJjh6OILMcCsKpy/NauiVwmX+adCTRvx+pk3o6jSOZF/uz7ftWsq69jjbk0HhMbl8LswjlTTs5WnI6pGANK8ZkfFmmy19Ncxy0amfaLjKLJCPlxIY+zc1RA6TuGIlOoiMB2o3etwpmeCXw2pEiwE+dwHyjtSzDs3Ttv1omWU3rkJ+gQKR9fc2U2QT90Dsv1yoMr0k8EVVCg9ix4xlBJZAVWntBtjc+PSC02Bwo4ZMQj3ryVUiBzQH1HrWlRPbhI1jXB3PlTEMKLbiCFbM76yNfDnnZAkZngJJw693krAMbU0oQMSCG9V3F3wbd7MJsouetAsWmCpFx8Vm2CBAI/2RR5WH9vHwfmEMY/IgsSVWNkHK+9CKpJ3FzRTmvOroOCC8UqKHsnVhataX/8uhsMPOFo3pxrC1cvOd/8qBzjtMf79QU21YnY95hWGARVRG+PK5gkt2vZydp4yWN/GIP+cccnBKrecwG4Ux2IwuITHvmtSOOn2m0ln8HkMkFJR4plFh1UtuU7i8ncFzjBY0oWCXz2YDyR31eYCWBvXp3f3ch8fAY3tsOx07EYBkWHlpw/yxQcYkvs6iL+D2X8vbUhbDPFKvtYkvJqQ56x8/6+5Eon04a/vHs1pCHTj/8vuOvRrIf9MGUXR+GlPGm/bcB4RwIM2QYIw4Ggn7FF+7OWeWHfJYek1fGOFopuz//Wz6WJ7lnNpkFfT8NYpK0L+xBOkTbK3JyqwPUVrJOKqMTMzwcVoN/dctzbMuoXp69xSfU7KanqEEFfAK+Tv0alYgfCruSt oSJs6XbV LFMKqo3NECLb/6bT0adQ0pMCjLzTsjBub7FJkPa1tVsWZKC3zjH356dlmGHhuLIGDQk3YqfpUkHtmjmI52btqwsJGqlzhidmeaG0duzjeR37nT2QZ6JqOX5xeSOCxynAY6UPXp7b94dfp9xcM7rkvvkR01o8gZgZUVSbaw+d2AJq0DpQTlDebUtg/EFHmj3D6nEOWroDdnuYDDMvf5HJ8WbA9apKKx6WgESPhByPgVNQGs1jnjg3G9GdEUGpfbtLLMbh7lawUlMc3xbQkCZUBEoPthHZKHSrp0FdTJFRqDARXv9/SUbZqKR3uUC8v9pimaQaQBPfxAJCSnw1iLnMlPShC82bB9QS5CDZhRUo3FuEaAe+63N788QIQ7aUKmoJk5RYifQKzDIQeaRoj17AMxQ563Yz5YlYlx6PoDlx6JsqyyEc= 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: On Thu, Feb 02, 2023 at 09:14:23PM +0000, Matthew Wilcox wrote: > For those of you not subscribed, linux-mm is currently discussing > how best to handle page faults on large folios. I simply made it work > when adding large folio support. Now Yin Fengwei is working on > making it fast. > > https://lore.kernel.org/linux-mm/Y9qjn0Y+1ir787nc@casper.infradead.org/ > is perhaps the best place to start as it pertains to what the > architecture will see. > > At the bottom of that function, I propose > > + for (i = 0; i < nr; i++) { > + set_pte_at(vma->vm_mm, addr, vmf->pte + i, entry); > + /* no need to invalidate: a not-present page won't be cached */ > + update_mmu_cache(vma, addr, vmf->pte + i); > + addr += PAGE_SIZE; > + entry = pte_next(entry); > + } > > (or I would have, had I not forgotten that pte_t isn't an integral type) > > But I think that some architectures want to mark PTEs specially for > "This is part of a contiguous range" -- ARM, perhaps? So would you like > an API like: > > arch_set_ptes(mm, addr, vmf->pte, entry, nr); Maybe just set_ptes(). arch_ doesn't contribute much. > update_mmu_cache_range(vma, addr, vmf->pte, nr); > > There are some challenges here. For example, folios may be mapped > askew (ie not naturally aligned). Another problem is that folios may > be unmapped in part (eg mmap(), fault, followed by munmap() of one of > the pages in the folio), and I presume you'd need to go and unmark the > other PTEs in that case. So it's not as simple as just checking whether > 'addr' and 'nr' are in some way compatible. I think the key question is who is responsible for 'nr' being safe. Like is it caller or set_ptes() need to check that it belong to the same PTE page table, folio, VMA, etc. I think it has to be done by caller and set_pte() has to be as simple as possible. -- Kiryl Shutsemau / Kirill A. Shutemov