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 710E5EB64DC for ; Tue, 11 Jul 2023 12:37:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DDF546B0071; Tue, 11 Jul 2023 08:37:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D90996B0074; Tue, 11 Jul 2023 08:37:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C7E516B0075; Tue, 11 Jul 2023 08:37:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B81636B0071 for ; Tue, 11 Jul 2023 08:37:11 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 70E6F1A0228 for ; Tue, 11 Jul 2023 12:37:11 +0000 (UTC) X-FDA: 80999281062.28.D6B6CA5 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf09.hostedemail.com (Postfix) with ESMTP id 1982214001D for ; Tue, 11 Jul 2023 12:37:06 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CkKrD0bR; dmarc=none; spf=none (imf09.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=1689079028; a=rsa-sha256; cv=none; b=6lY7gjMF/AkwvGGVAcbt6e/xjQ8D9OZ8R1uM4zswpR4qDQjQEufXaCL5AZjC73YDAEDfzx HaRv8moGvicGSQJBC9WjN40NXp53WvU/B0v8tbiji1EB5AYE8/9fcYTG37l7LjD8v/QUTP mFrNK/jjMnW4Ka+9R08DkC3L+L1Z6Ys= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CkKrD0bR; dmarc=none; spf=none (imf09.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=1689079028; 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=KlnB2tfvK6zA01tMfE90usFEigtkyKBwlIV/RGlhbEc=; b=dYKk1FXGHUUgAE9wTkbyJcSvkxhErfjvFenjrwvKGB6V/gn4cRIEViHvl7tlOSiiT9mlqy 51Q+qijymzAs9RQgmaomdqLsmEhumgOzrM7T7DRZlQpzH2Pg7IMKSjsbODaAXMwMBH8Iy/ 34tHTiizthALbCeL0ZZW6YCD51RbLRI= 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=KlnB2tfvK6zA01tMfE90usFEigtkyKBwlIV/RGlhbEc=; b=CkKrD0bRwFnd4JjbmnZV9d1FGE NFbm5ssns3ISKSsdZDQ5sCU7+tQkCpLVQbHcT0E/1gtjNJkJTIevFzmqkbyZuf1Mj4AqYOmSED1oY umjsfhCQO+J+P/dyQz4emavUaIQwzN4mUBFwsi/OFX3cVouA7VRKiagiMcPVCvFMD7FjQfkcDwm25 tWFIT6suFiVLnOgPzk18GpdH6f+xuVcN9BSpLD1MAVUNtarIxQMweeF7hG7KZ/7x361aB1MTP5PJw uVeSSiX9aso+xhA1lEWInzX6tudKcEoN9mbD8Gb7qNTipA3Ko7qBwt9lK1qJVIWREeGv+eZ3IukD8 dskKbcOw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qJCbT-00Fid1-AK; Tue, 11 Jul 2023 12:36:27 +0000 Date: Tue, 11 Jul 2023 13:36:27 +0100 From: Matthew Wilcox To: Christian Borntraeger Cc: Andrew Morton , Claudio Imbrenda , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Gerald Schaefer , linux-s390 Subject: Re: [PATCH v5 00/38] New page table range API Message-ID: References: <20230710204339.3554919-1-willy@infradead.org> <8cfc3eef-e387-88e1-1006-2d7d97a09213@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cfc3eef-e387-88e1-1006-2d7d97a09213@linux.ibm.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1982214001D X-Stat-Signature: xja4fjmfuzbarzabwsyxcue3www8sn7w X-HE-Tag: 1689079026-539939 X-HE-Meta: U2FsdGVkX1+6pp2pzms9hBTBY2j6oxQFD9ZCc9BjRgaKAJ9pFze4bSUlw7l94xWVj/JDBxyNbliF3yLfrt3sek7VOQQFIDjPfhRuaWq/gxLXp4PHjHDNFJIEVLn/yaLqHdQBGjn2s1Rtg3W75sHbDpm0ga9nf3TRmtYSUT0JPNwwSU+IkGsx7pOFtgYzeGA4lKWBtubto0cJiMfg1gN7WLGOCZSisalP12kF1+LlfmQFwTJVlIVFAUYXZEpGmPFNp5NTyF0enWw8nBKno9APgtfr3kY7RDQosuWn9802XuU0MiZcjMbqoEyrze0YiCAX0YCn9i6HBwKwYwgJbVoFzXP76sulRix2nTl/N578YxAFdiuOCS/zEImL725RUZfAd8WpDTVXo2RmDlXfSfLBIFVjuoU1+Vx1r++mYgOFciWHDq0QnXsmpiqaD+81cqN/OuPis9hWXUQfBTZ+279dl11JYF5yjydFmLfME+Hp2dnxw2TWklawga/nsoDhBWNVyS7PNMDpSWilBaeTmQEcOOGCp9V/d6+oKbFE+lqk+JjxPHbEgA4HUg9qHaPW+RzhPDuUMVKDNv8CjGgvUdK+Pjdk0bi6reIvii3p2Xj/orwSKWXc1uSrOnEq1r+bfJHPHfM1zV9eRB0/znYh3LbmDeZdanT8lUwzwgiwmHeDXyTWWsHaPElEyf0eoUo+0Y8d/6AINxL9W5qI5Hl072H4/1+dUsSGsKDmJbSaGrnDX9YQNETs0hMP0KQSRGdyle6L7tku405bKhE3AgQXy6figAsHC4PoAz3qpSO7t97hLPOOFwFAIsqLr4yEjJTgFv4R644fNGAcONTbhK8Zohiq28G+WU5/jfcOAjicpQ6xEf2G6feYYWhkp4vZEFMuT8Ilh6qR0GP2O+Fb8vLKgqWwecgueIN1GU88z6bvMhZd0zLHDDGbh01M3AA+57dzrAn1YM8MU9VfFjJeeKrz4++ c27BQaYH md/AavVbj5uvbpEpzp/HD1+ocyen/2dz1lSjBQkDitP+N6p6MGidPx3drhUdEXwYCifN0akJIqv4fSBk8viiA9JflMbTBytX8pg7aL6PKyIxQVMW+MVnE8pqwauxJ4Kc5PkBt9gnbf1nb5uU= 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 Tue, Jul 11, 2023 at 11:07:06AM +0200, Christian Borntraeger wrote: > Am 10.07.23 um 22:43 schrieb Matthew Wilcox (Oracle): > > This patchset changes the API used by the MM to set up page table entries. > > The four APIs are: > > set_ptes(mm, addr, ptep, pte, nr) > > update_mmu_cache_range(vma, addr, ptep, nr) > > flush_dcache_folio(folio) > > flush_icache_pages(vma, page, nr) > > > > flush_dcache_folio() isn't technically new, but no architecture > > implemented it, so I've done that for them. The old APIs remain around > > but are mostly implemented by calling the new interfaces. > > > > The new APIs are based around setting up N page table entries at once. > > The N entries belong to the same PMD, the same folio and the same VMA, > > so ptep++ is a legitimate operation, and locking is taken care of for > > you. Some architectures can do a better job of it than just a loop, > > but I have hesitated to make too deep a change to architectures I don't > > understand well. > > > > One thing I have changed in every architecture is that PG_arch_1 is now a > > per-folio bit instead of a per-page bit. This was something that would > > have to happen eventually, and it makes sense to do it now rather than > > iterate over every page involved in a cache flush and figure out if it > > needs to happen. > > I think we do use PG_arch_1 on s390 for our secure page handling and > making this perf folio instead of physical page really seems wrong > and it probably breaks this code. Per-page flags are going away in the next few years, so you're going to need a new design. s390 seems to do a lot of unusual things. I wish you'd talk to the rest of us more.