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 543E4C74A5B for ; Fri, 17 Mar 2023 03:45:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E8D2900004; Thu, 16 Mar 2023 23:45:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 699DA900002; Thu, 16 Mar 2023 23:45:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5876E900004; Thu, 16 Mar 2023 23:45:21 -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 4D0E9900002 for ; Thu, 16 Mar 2023 23:45:21 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0A92DABF68 for ; Fri, 17 Mar 2023 03:45:21 +0000 (UTC) X-FDA: 80577000042.03.9724FFC Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id A7F9780013 for ; Fri, 17 Mar 2023 03:45:18 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=j2Tw26G+; spf=none (imf02.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=1679024719; 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=qF107+j6GAuH3RxQoYDUVv0pRB+DB/rZIKen3lbmswM=; b=vPkFB4o4OuD8zPhp8h6gMrVsqjOjY/Zpd9zaRh0piWlzFLreyKWuQ0x14XNMWZLHbZNbga CD6MgC6O88/u390+L04Cnr8ZPuqBMlbji8eeFwiDDdYPrZwrxT/CB5HYGbMjPoD/KX2CNL hugRqoX7Sv6aD+oLTP2cig42Id6J+qs= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=j2Tw26G+; spf=none (imf02.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=1679024719; a=rsa-sha256; cv=none; b=AtDptq3Rg59Y1hFt7ZpCxYnWFKXWd71j6rQFySLOmO3IssfNqm4yqnpJnaKgHdW/7gy/cV BFEoae/ev4ukm5huq1Gq1oRC307akjoinL49VdyqwTPxeZ17xSjY2Y75iWCtcSJQKzQiHf 48Rzu6iXUUxPnSfwvjAZpSu7nXsNIPg= 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=qF107+j6GAuH3RxQoYDUVv0pRB+DB/rZIKen3lbmswM=; b=j2Tw26G+DFxuBZBc4zZKT+J3s5 XwHQAq/SUUtueB9ucrLUZGtRcylwrC1NL/krcmZJ8pyvmt8o1ZcPc4z00d04PqjMJcjmAv3UXmFEi feGW57C3Drx32F5AxFrfXuLSE4kxIGcUdZ+BK/kuTNqNrMWp6etYlsxByrcyV+XpwHqqlaLOhEykB Ky1LoJIzkA9iOriueRGr5f6dCxrC+Z3aacWogDjbaItbf4cgFtFt5CY839Y4Q9nuq1CVgr2kzuBnE Ibi3sqp5verctmlRGpvbvMtbsWvv705ub64mujX3P4zqdBVMMnPHiNEBAwFn4T5BfdeF+swpVmV96 82+RY54Q==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pd11W-00FT7F-6g; Fri, 17 Mar 2023 03:44:58 +0000 Date: Fri, 17 Mar 2023 03:44:58 +0000 From: Matthew Wilcox To: "Yin, Fengwei" Cc: Ryan Roberts , linux-arch@vger.kernel.org, will@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 35/36] mm: Convert do_set_pte() to set_pte_range() Message-ID: References: <20230315051444.3229621-1-willy@infradead.org> <20230315051444.3229621-36-willy@infradead.org> <6dd5cdf8-400e-8378-22be-994f0ada5cc2@arm.com> <2fa5a911-8432-2fce-c6e1-de4e592219d8@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A7F9780013 X-Stat-Signature: qgn1hbsggoru14bbikhr3bc54pkisx5n X-HE-Tag: 1679024718-763014 X-HE-Meta: U2FsdGVkX18N9hkzkJaGKNVrFDN1vIfP42cTg6odtRjGnL5v8JklpCgvi/WplToQosTEIwY9NItyndpqShF84KciA2aggF6CeVFU9OgQrTLMhRZG9wja5/Xz79S5z2fUXphUpSsdbOYRHPX3wuVf6Kb0EwpEAC6fhNce/0dfN2GKgJOfA7dEKkJpjfNZ+bpcuJnI9iDYiHBFCQos+5Xnh09EzMz/2jnN2GlClRLRVpFmG/Ke2TL5IXAoB3RooQvnRTuFz3qUteA9YKSKrZx4rMe8hMv7apl2tyI857KThSBWXNacwExeBzYRZp+T59NhV/rqp4U3oO/7QUEYpXDyJgizP24h8g8xxlbDctfB0MkobgUU3/rq1ARp6zjA7ci+w/rlo7sDPG1JY6WeY0R11UU+fB169nyDNMJWSMAnD4Ke6JkazdeVYj6+tuTIPNGixKYRNaMCJy23ZsMG4MYsA9aoc9sjJGevzh5JTO4p/AE31/brx8rnpJgVaRVOHcuG0k3NRo+VOMBzDkXpkywzaElHRPrhhBhrKciuX8Oc+Aa84tdxJsmnz9a6od7TtYzEICAlWBAkRwI5Go/4KQud7wt2ZaqCVKu2XzCQmQcVC5q+mxi+kMfHZAhg5V+3j+NXZ3tMjOoGCsn6fY9X4lBV+tw9LYdI832V+8OfZSDLLP0iEvsNNrVSOK6vxoSWlHBBPnxW9yZHzNHQsWvvaLXoUhhuNwVq19K60UIiFNFmVRwWx/Ay3OvV66QPoC01t3IXqLDY3B0F8+wazgRKoqpUmpHyfb4/63DUQk3HoxkEYudCcdVZoLVIuHMHwFZAi0/fjh4IwxViphEjaNR+6ksyHRbQVQnLSPYD68s/kSpnoUP1+NEJ1F3aZH+dYPOahIhHng3QJtBzONLxKFIY2z49kSlf1clbjk4L1P75qK4vBKTrG3CxX9UiVU8LCBZY/7zznVqEyyuZC+Jcijqub8T k/GCBnPm lc9Eobf6avFfUneh3tnIoUUiapwyKgMSWyaOoPSNNdS7jqww+hzHIoChcuPc5BKW+x1a/W6fiEdQLJqNZsPWN8vPevaFRQnetqU7d1SlSMpDEcNK6PWrSIe3EYNaf8nHKi1XJQBd9JRqp7EYNffHvCAD5YV5Lc5zrKeVINd4hn8cN0Clsnwe2UuNi6HAWMOXdNRWHldxyH4k0ef4= 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 Fri, Mar 17, 2023 at 09:58:17AM +0800, Yin, Fengwei wrote: > > > On 3/17/2023 1:52 AM, Matthew Wilcox wrote: > > On Thu, Mar 16, 2023 at 04:38:58PM +0000, Ryan Roberts wrote: > >> On 16/03/2023 16:23, Yin, Fengwei wrote: > >>>> I think you are changing behavior here - is this intentional? Previously this > >>>> would be evaluated per page, now its evaluated once for the whole range. The > >>>> intention below is that directly faulted pages are mapped young and prefaulted > >>>> pages are mapped old. But now a whole range will be mapped the same. > >>> > >>> Yes. You are right here. > >>> > >>> Look at the prefault and cpu_has_hw_af for ARM64, it looks like we > >>> can avoid to handle vmf->address == addr specially. It's OK to > >>> drop prefault and change the logic here a little bit to: > >>> if (arch_wants_old_prefaulted_pte()) > >>> entry = pte_mkold(entry); > >>> else > >>> entry = pte_sw_mkyong(entry); > >>> > >>> It's not necessary to use pte_sw_mkyong for vmf->address == addr > >>> because HW will set the ACCESS bit in page table entry. > >>> > >>> Add Will Deacon in case I missed something here. Thanks. > >> > >> I'll defer to Will's response, but not all arm HW supports HW access flag > >> management. In that case it's done by SW, so I would imagine that by setting > >> this to old initially, we will get a second fault to set the access bit, which > >> will slow things down. I wonder if you will need to split this into (up to) 3 > >> calls to set_ptes()? > > > > I don't think we should do that. The limited information I have from > > various microarchitectures is that the PTEs must differ only in their > > PFN bits in order to use larger TLB entries. That includes the Accessed > > bit (or equivalent). So we should mkyoung all the PTEs in the same > > folio, at least initially. > > > > That said, we should still do this conditionally. We'll prefault some > > other folios too. So I think this should be: > > > > bool prefault = (addr > vmf->address) || ((addr + nr) < vmf->address); > > > According to commit 46bdb4277f98e70d0c91f4289897ade533fe9e80, if hardware access > flag is supported on ARM64, there is benefit if prefault PTEs is set as "old". > If we change prefault like above, the PTEs is set as "yong" which loose benefit > on ARM64 with hardware access flag. > > ITOH, if from "old" to "yong" is cheap, why not leave all PTEs of folio as "old" > and let hardware to update it to "yong"? Because we're tracking the entire folio as a single entity. So we're better off avoiding the extra pagefaults to update the accessed bit, which won't actually give us any information (vmscan needs to know "were any of the accessed bits set", not "how many of them were set"). Anyway, hopefully Ryan can test this and let us know if it fixes the regression he sees.