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 2701CC61DA4 for ; Thu, 2 Feb 2023 21:14:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8658B6B0071; Thu, 2 Feb 2023 16:14:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 815506B0073; Thu, 2 Feb 2023 16:14:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 703E16B0074; Thu, 2 Feb 2023 16:14:32 -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 5DB3B6B0071 for ; Thu, 2 Feb 2023 16:14:32 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 313F0C1045 for ; Thu, 2 Feb 2023 21:14:32 +0000 (UTC) X-FDA: 80423605584.28.A2EC4B8 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id 8755114000F for ; Thu, 2 Feb 2023 21:14:29 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=jdCCdDnh; spf=none (imf23.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=1675372469; 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: references:dkim-signature; bh=6gOmrh6KL+tVKssvgltz89sdjPllEw7CiVRL9HRHcFs=; b=IrtwzcFvGAz32lWiB7+uDtgXztzoR/e1a2RzsZG8J06/PMUJycXytgzTpVjjqc0aMM66Mb KGNzzhzweRk9n4EfrcjFFajbKsos4gU9JS9kQ3ZDLKibDgDzb665HSPFpS5P7BhSkVThNh LjKbE9rQGEO9Esmbr9IonV4n1JbtAsM= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=jdCCdDnh; spf=none (imf23.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=1675372469; a=rsa-sha256; cv=none; b=XJzk38DjnXU30wQk/0nIWybz+et3BNcPlIjkizib/J4jFFpR/2gP0aWZC2hgbv/102H29O 0nUPtXakJWqVCFMXCgPq4CBIrueZt5uqCK5LEP3deesDvIwAWoXwwcXTu3WIPHY+YqnCJA C7825j9NOpBP+Aks3VF0DMCIsMwx8QE= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=6gOmrh6KL+tVKssvgltz89sdjPllEw7CiVRL9HRHcFs=; b=jdCCdDnhIdyx9NMQjJbhl3GGlC 0e5dQ2o9tFhAPmeoe/nn/Ig54P05PiOmN8xl83uKlIEaYignMdKlC9oT2Ga+l+wZHDlqqptHydY5R ojo/dWUZm+Fi86iQlNOTp9WdqKSscd/owCjDqbb5vZI1l6iRRiiIRr9GC3eS/vPKdlAYgCsi7un0u l6z0mc3bhlM+ObclMlvhsIfyD6hzHWodlkdYoe7T9KUxTgpqIdUdjVKrrWYPijvZbkrRj6o2CyKx2 7Obyw7DiXVnUCpyinvs4Zsf5Kwax/QzXtPta8RvLR9qhrQ+eDQh4S88geRhYyN1GVge42GVUvHzF8 dj52WncQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNguV-00DjIY-MF; Thu, 02 Feb 2023 21:14:23 +0000 Date: Thu, 2 Feb 2023 21:14:23 +0000 From: Matthew Wilcox To: linux-arch@vger.kernel.org Cc: Yin Fengwei , linux-mm@kvack.org Subject: API for setting multiple PTEs at once Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 8755114000F X-Stat-Signature: fhmm1gderscrwq4ywr8g837xekq9tsuu X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1675372469-778817 X-HE-Meta: U2FsdGVkX19iESkyGIW0K5T6LPUYnjVvauNL03h53zKrnbQMzbkgYDqfSUvTdF0ANLtW2B4crGF+vdjlXSG59iCjINMF3cNg5M36bc5HBz6WtXYRMc81fB1b6Dz6Q70MynNANIxH54uxivpxGIoYRR23xcM90zGu7pHHP90oDQJYyoznm+LTHw21DOmWAdZUbFNq1gzittVlrsItvRI+xCGTsPi3r6UeQc1ptWDWmB4I4i0tX5EoXYsY/v4JGa9jDOYbtwl9p2XDeffUa74MT18RE6mG9IprGCfjWIoGPte0U5Ihdss9A169u8MLV/v18PfAk/9kb2BZi8Uw3Tg8FERvnPm9a66P9heRhatk8/59gM25/ZqRLcCrxCcNhiCAeI+drIyXkqowdAc6+XZhEFYiJ5cjPVnCMvzKPX6595M0NAWQLOC0ZWmywgty2poNyLk1Qly1Teyc6QXaFvIsI6EVcN+YAjwFNqX4CY5742V9dXoh+XGwOJGu2pf6emhwTgsJgyf3PTLOzg2C24C/d0Y8dQd342ACMk796N2jqczk6MjyV2MdIarFx3TBzvKF9wbkx/h8nt2ex83h87lSqHqkjEHrTCBsazA4LLxuYYJLtgLZzP/ecBUD0aVHiQttmTZ7ueWoMqfUm51wCQQarQEUYJA9SQqH9BpcEBzPn1QDhytKAHIiPOVtPsT6F/ypJwfir9ABXraUVifI/4+JD2cr6dSAnpobim1PhP7Rabk6/vzp73pfjMKi3g4xzb+TICHJGSjg8wFIQb+H1vM28oqTxZCmakLIR0AB7+s5rNVFE+bbf0tfAbqUJV49Wx41uRF4wnQSVDYw5DiNkEtbf2GZs8jTnlVcbHNOw0fCU/CnDCsmKpOPZnGVUMpdrQT/lCWau0R4ESxTcd0UYiHq6mI2wA0Ym+ugBvBhDVz7QKtIXjGGOi0l3+lTyePoPw/m7Oo+qBLSBwdxXLxp53S soQZ1coV tY6RVK9H1x6OrAqxtDWbfplu2gosWSXx/CkQAalM0cZ6emw48Vif4jbiq4EonOfwCM83eYDXLCvWOv6ywXWJyTp714Vnsy1Vg37grBVMVO9G0/BmAs1OPa2mbxMokrIo9c3K4nfkdFhqIUIUpKjL9rdr+4bOor1gUKgYcd1OT2rRm/iscJgn8/csooMTbNEzZNWE0kQj5GkJR7dvtdZm64AhG20BXJM53zVgZJICvjM/UizX7F0IwT4TFvK/9kaR6kU9a/NGp+rBry78= 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: 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); 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.