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 9CCD0EB64DC for ; Tue, 11 Jul 2023 22:03:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D4716B0071; Tue, 11 Jul 2023 18:03:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 060A56B0072; Tue, 11 Jul 2023 18:03:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E1BD96B0075; Tue, 11 Jul 2023 18:03:47 -0400 (EDT) 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 8E3A46B0071 for ; Tue, 11 Jul 2023 18:03:47 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 56E28B01A9 for ; Tue, 11 Jul 2023 22:03:47 +0000 (UTC) X-FDA: 81000708894.19.5C3503E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id 8E11514002D for ; Tue, 11 Jul 2023 22:03:44 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=dM0kbTdz; 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=1689113024; 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=ruHFUTBYjMeb32nlu48tPWaF8pJMw/xDaOvIEKoJxjs=; b=plPaUXX9Z0ZnwIIpys6zHYdXtOzzU5ipC2cXxepEtwZwcmeXezPV6EqauxGDJy6IAUz4KM QA8iPxZQpdd/sr5lZWhStu2ZDwo5Ud3rXs2L7Cp/VWUh3SUchZT5qhnd2P1yxtNdOtQnrA cDsTxRUm9j0cSn4MSnAGuHz1kxmPPZo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689113024; a=rsa-sha256; cv=none; b=Ww1HVdnbPLdvHEPakCBcy6RN+aK47RbreDjPvhPufAmMLHg0l3EazkQgy4nMeuNblNKQLJ Peh4liQDxaR5CXCrg5vlWZoxHvSYXXGO4Zco5zl+A0qhGFOA6Y/08zCWsaxm0WsdOAh9C4 1GM/XO7sQ/KlPDy3uj3DNMwXjqLy700= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=dM0kbTdz; 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 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=ruHFUTBYjMeb32nlu48tPWaF8pJMw/xDaOvIEKoJxjs=; b=dM0kbTdzbqKGUs8PimqMlhNiuL 9K4ZZr2jq02N7HlVgZJqCrsXNsqTj6GnaTbU8l/IjScJNP6nakX2h0eCO+bC333AGt7nU/hvME/Lj ZHVdPns8UL3cG9OrzULU08YpFnZGnmAjWcNiDKuWfUwxQv1RqOmOCHD3fX4RJTaARboBTqyXv6dHZ 8udt53NgleBXCmfQNQEp22OAtqArpSuFhdiJTOSQIrSPtxCceljxvAiJLDr6q9/hhcD6V5kDiDN+r 3avXUTIcn9afQ0u+MWJAaiMKgXRUqGsbdTmuRtkfYVLg+w2KIXqkL0lYcqc1RUQhDqk3Fi0X2Vn0v hEDneSog==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qJLSM-00G5VK-9M; Tue, 11 Jul 2023 22:03:38 +0000 Date: Tue, 11 Jul 2023 23:03:38 +0100 From: Matthew Wilcox To: Andrew Morton Cc: Claudio Imbrenda , Christian Borntraeger , 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> <20230711172440.77504856@p-imbrenda> <20230711095233.aa74320d729c1da818a6a4ed@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230711095233.aa74320d729c1da818a6a4ed@linux-foundation.org> X-Rspamd-Queue-Id: 8E11514002D X-Rspam-User: X-Stat-Signature: ubzyebda74wo7ng7whtj6dsjmquf7xpe X-Rspamd-Server: rspam03 X-HE-Tag: 1689113024-311073 X-HE-Meta: U2FsdGVkX19jx8+q5j1f2+Km4xNYACKErAMwlh9dA9IFb7haYaIZ2sNHqG9KgiHegfNQnOmHcGnixSq4OEQoTcm6vHlU4bWvpwxtY9l0Yy654XeFmKTtMWQoiNuMolFsaGAIHM/7JJAHIc06smKY/2JLOFJyqNpsfrD/beEBYLs1pdO8jFv+IUUdmVHyuB9vk+cwW/KWNqA8I61G3GqmhgK6GuXZ8YpUgyav0/itbL6I1USI2/6qbyCTbyFC2cqdkCE2yTIl3nn1S7aGEgMsrF6ogQBKMBdpc0A+y9wW+6YC2xlr9rCch18F1/Qhlx6UAdfJd/y+HzgoqMnotmbyrWgL/36Ha0ms+eYvp5HP3Tom7jzJy0knHSca83HlOQ7LcVyuIZxXmoHe6iAjdHeJ4UtSK4hJkmYfDYawb4aYVH6jy484iRTFMM71wtMCIF1NQX2LscWq/oMkLu6kHohkiUq+sQA7KMzWYSXjoNDtYKzjHm24dT3o8hGAcxFzbDPzkA3HjNWQjRg7OmkxGlMerB43JDRoziQjQpEOSrG2QgnQBMOTnKqbf8isxgFeIXEwIQk2yEwW7M8OMLG/rc1E/7h7mSNP2Hc0dT37PRY1SxQd2WHn8EWViUrUyKJjuEQG8JIcu0By2DqpT7YYo6jXPLT9a920ktDTXOkPlIBG9oqjGyFbw5EuaxGBRHU5NwKCC7ge3KOCrxTOcpdShtG6PV2tj7m7av6MDhK4bkZufTmbNnMo/7sS7WcSqdSAOa7dWJU/TwvYtfBwWinPY2J54XPYAHYs5nPDcwBBQWeie8jmN78f0r1B3aUwvNj5U/eg3MRNElmDCiyPC4N+A82Xxvu6LpbDS+HzXvd3KzeGLV90vt8aNwz7DOAvNNA2B4cxxF4NzZXLoC1vdlSscGJnvAQ5awJ8M7GjWe2v7GdrGeaXdFcz+OyJG/w9jfgnkhnIYDQpaQhJ/Tno/eLkOgx KQbIkeiw yh6ziexiB6k9MjD/EbwkTbup4G0Q1zAqzbzREOsaEWwVhMeEO+gdgBsGVgqofg+bMw7o4X4CmRqfauasjIU0RyjwVzQxGr529V3uNlow8P0oWmOFnIzAr/ANhh5TaC6keGtzfRYrKMBTgRU4u/Kd9PUSwXhuZRKMNsCBqRGZ/QV6Sa1i+6iJd+FXhS79J8uLsRxSsbGllgNR0y1JGCPjRqFUh9Q== 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 09:52:33AM -0700, Andrew Morton wrote: > On Tue, 11 Jul 2023 17:24:40 +0200 Claudio Imbrenda wrote: > > > On Tue, 11 Jul 2023 13:36:27 +0100 > > Matthew Wilcox wrote: > > > > > 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 > > > > For each 4k physical page frame, we need to keep track whether it is > > secure or not. > > > > A bit in struct page seems the most logical choice. If that's not > > possible anymore, how would you propose we should do? > > > > > need a new design. s390 seems to do a lot of unusual things. I wish > > > > s390 is an unusual architecture. we are working on un-weirding our > > code, but it takes time > > > > This issue sounds fatal for this version of this patchset? It's only declared as being per-folio in the cover letter to this patchset. I haven't done anything that will prohibit s390 from using it the way they do now. So it's not fatal, but it sounds like the in_range() macro might be ...