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 B47C5C6FD1F for ; Tue, 26 Mar 2024 16:53:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 31A596B008C; Tue, 26 Mar 2024 12:53:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A38D6B0095; Tue, 26 Mar 2024 12:53:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1449F6B0098; Tue, 26 Mar 2024 12:53:53 -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 F2BE46B008C for ; Tue, 26 Mar 2024 12:53:52 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C86A71C0EA9 for ; Tue, 26 Mar 2024 16:53:52 +0000 (UTC) X-FDA: 81939787104.13.4732675 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf30.hostedemail.com (Postfix) with ESMTP id E0CCC80015 for ; Tue, 26 Mar 2024 16:53:50 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711472031; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BW40xg6RANk3HG4/VbPnFOeVIXEryfdQ6fs26IFGZOA=; b=gYJoB3FZLUnm5RffeQLhGJOudUhmFhJZPdjXyI/Jop/BhvIvOYGj/ZE1OWh8EyGQvTkZnr C5atUR2raNq3dnfOe+VTRAIaGgrztgkfCpjOC5JdSlV/VCu115mjLFTcJmxLb1Bc7N4kIP nXoi4yIdipRsliuDyDQDLx9Y5/1G/5k= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711472031; a=rsa-sha256; cv=none; b=gbyHeSV8LoVoJXRemS4uW3UXthsK7kUrNBMOstduBIOyc78y/wmCJnglOYBT1P7EdxMMcl YPuw+aCKcCK7Ut8ioCBd52K6U8G6uPKJHJIUO5V1k1lw9mlO5gAHBRt7/bmPiAPjs45Knh uVQ2hwha00ik3GLdVrY0ua47KfLXldY= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A704D2F4; Tue, 26 Mar 2024 09:54:23 -0700 (PDT) Received: from [10.1.29.179] (XHFQ2J9959.cambridge.arm.com [10.1.29.179]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7292D3F64C; Tue, 26 Mar 2024 09:53:47 -0700 (PDT) Message-ID: <374d8500-4625-4bff-a934-77b5f34cf2ec@arm.com> Date: Tue, 26 Mar 2024 16:53:46 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 0/4] Reduce cost of ptep_get_lockless on arm64 Content-Language: en-GB To: David Hildenbrand , Mark Rutland , Catalin Marinas , Will Deacon , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , Andrew Morton , Muchun Song Cc: linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240215121756.2734131-1-ryan.roberts@arm.com> <0ae22147-e1a1-4bcb-8a4c-f900f3f8c39e@redhat.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E0CCC80015 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: ao46a5b4ui4kat8djhzuo6kdnt5tq5bt X-HE-Tag: 1711472030-640671 X-HE-Meta: U2FsdGVkX18TBlfhEb8hTr2ox9Fi7PlIi62UzYIPowsh8ecSRUTL9Ql0fJ3Sp0HIXu7NobFTvluDjHh531lhjuHQlhR9srffhuhh4Wj9TRq29vqwV49oLzH/zYsjrRxBh2WBl3Ku7OAn5eQ9/QzAiN66Kuvj0SWGsBC1fenSC4d5C/UoLQOrXeTuj4gS6acXfPE/YbQcaAxOTEiM7G0epL4X5rLyer2X4KA97xBCF/9puWepEn1hp2dXvcNYx9JWy1d+3L3E8qWe7SRVgCLrkuJ+j4hm3FmGRXVl9W7D85Lj+gZmlioRWpvAZBre8DnUF4hZwt2f6fu/Oe0aLbLNs2xpJNIHmM2r1Amx6AoWUiGZLxhyl0Cb3HVcIy+74QjY6AQo1JHzhYSVNLetLvRiMxpg6JMlHax5l43lqIo5K1iU7HSsSlOcQ/4eWBhpWzkU9YaWS7Lh6557tenMTDeUKhkpyYx4f267Z4+G59fth0IXFIlDd7fusoojZ8n7U3u+N/RCOEnWMQXtjiep1JQ6NwojJ4YE2uWspoNdNoD09qubi3QZrYEbO0oBIFpIFKDWCHWTG0pqxNuigJK02HkIE7cmzjzyokGf7oWqgT8mdiDjyGvBQ3NhPkPZ1r8Alez8tPcVEUV/VFhn79bC42WU0C+8hMZVM+pczJwGImBS8gq3UAxuKwfc8UDI5aAFouTwLFTm8E3AoaGIE/u7GSwz1z4oQQeHkSQyXpvhBhmWbusaAjJliTgX/VBGp8ac4VF7YOmFfhMbZ3PqK11SnJ8ZzAPX9BEVo/aCLq0Usg67cW/24RMPUCt5jhq3qgbooeYvSWAjUojg+8Es30Q8zf0E0wPiULpCcFAmEBehQoHB1ykR36+S7XPK2f0lYg3Gnz2LwuE3xPUkDMqjVv5777x0p3bGJFaaMZUnNyoHSFV5lSZm9ec47nsY/fM3AGq2csoGLHIVhfSgWgkWw6ZS+Jj DwE1SZTn DGRQSI+c/DZe1bwzpRu+8S6DjEVqRFbRn/t77mKoGpFYzAtGwWeWJ1qsY0p5D3LaqTeFbB3EsoDq05PtRI4S6Z3BVXHc4lfphf5NXQGSI+SI19bdFxxB5D3rPdlgVmnDegMpvogZNYrw3+IJa13Zw87Pwbo3T8Io3N8v3xSa6UZiTma96TnwzQDG9GklwPJKorVH2 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: List-Subscribe: List-Unsubscribe: On 26/03/2024 16:34, David Hildenbrand wrote: > On 26.03.24 17:31, Ryan Roberts wrote: >> On 26/03/2024 16:17, David Hildenbrand wrote: >>> On 15.02.24 13:17, Ryan Roberts wrote: >>>> This is an RFC for a series that aims to reduce the cost and complexity of >>>> ptep_get_lockless() for arm64 when supporting transparent contpte mappings [1]. >>>> The approach came from discussion with Mark and David [2]. >>>> >>>> It introduces a new helper, ptep_get_lockless_norecency(), which allows the >>>> access and dirty bits in the returned pte to be incorrect. This relaxation >>>> permits arm64's implementation to just read the single target pte, and avoids >>>> having to iterate over the full contpte block to gather the access and dirty >>>> bits, for the contpte case. >>>> >>>> It turns out that none of the call sites using ptep_get_lockless() require >>>> accurate access and dirty bit information, so we can also convert those sites. >>>> Although a couple of places need care (see patches 2 and 3). >>>> >>>> Arguably patch 3 is a bit fragile, given the wide accessibility of >>>> vmf->orig_pte. So it might make sense to drop this patch and stick to using >>>> ptep_get_lockless() in the page fault path. I'm keen to hear opinions. >>> >>> Yes. Especially as we have these pte_same() checks that might just fail now >>> because of wrong accessed/dirty bits? >> >> Which pte_same() checks are you referring to? I've changed them all to >> pte_same_norecency() which ignores the access/dirty bits when doing the >> comparison. > > I'm reading the patches just now. So I stumbled over that just after I wrote > that, so I was missing that part from the description here. > >> >>> >>> Likely, we just want to read "the real deal" on both sides of the pte_same() >>> handling. >> >> Sorry I'm not sure I understand? You mean read the full pte including >> access/dirty? That's the same as dropping the patch, right? Of course if we do >> that, we still have to keep pte_get_lockless() around for this case. In an ideal >> world we would convert everything over to ptep_get_lockless_norecency() and >> delete ptep_get_lockless() to remove the ugliness from arm64. > > Yes, agreed. Patch #3 does not look too crazy and it wouldn't really affect any > architecture. > > I do wonder if pte_same_norecency() should be defined per architecture and the > default would be pte_same(). So we could avoid the mkold etc on all other > architectures. Wouldn't that break it's semantics? The "norecency" of ptep_get_lockless_norecency() means "recency information in the returned pte may be incorrect". But the "norecency" of pte_same_norecency() means "ignore the access and dirty bits when you do the comparison". I think you could only do the optimization you describe if you required that pte_same_norecency() would only be given values returned by ptep_get_lockless_norecency() (or ptep_get_norecency()). Even then, its not quite the same; if a page is accessed between gets one will return true and the other false.