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 4BE9FC10F1A for ; Tue, 7 May 2024 09:39:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D76D56B009E; Tue, 7 May 2024 05:39:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D275B6B00A3; Tue, 7 May 2024 05:39:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BEE226B00A5; Tue, 7 May 2024 05:39:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9CBA46B009E for ; Tue, 7 May 2024 05:39:57 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 646E8A0AF4 for ; Tue, 7 May 2024 09:39:57 +0000 (UTC) X-FDA: 82091103234.07.44CF9A6 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf08.hostedemail.com (Postfix) with ESMTP id 92673160012 for ; Tue, 7 May 2024 09:39:55 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf08.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=1715074795; 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=7MUID/OfGQvgsbYFzpGwQOg0PPD5yScxfKPTKoTM+8c=; b=2igQCkeOAI7RUpugGbGpbzWpT+dcZDjaBHaNdYxY2BKO3nGdUuqoC6q6+nGbqMY/+bjYOj q5SvPO1iS6Ox3OTFK4KtTRL0Vjz0bfRjw1XF+aOO3ZoJhzHP/faAH4DjXTBsi56ogUru1k gDlgc9KCC+fOpS9/UqHxY7BFedKxghI= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf08.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=1715074795; a=rsa-sha256; cv=none; b=bZZroc/JoFECoERL74hlUbHuQFx3g7gfSpr8pCn+GDyaR2L4Tu/ezfnZZyvP8iG0rV/yGh ww0sLf5LHO2c5fmO0h9NWSkuMFkTm168/CIUFVT0eqKsj9RGCxl3Yp0SIfyqFU1Rri5kvz 7yL/qXc8uqrXE4IXtgmAtcaZ2NcLsEA= 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 A3AC01063; Tue, 7 May 2024 02:40:20 -0700 (PDT) Received: from [10.1.34.181] (unknown [10.1.34.181]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 619EF3F587; Tue, 7 May 2024 02:39:52 -0700 (PDT) Message-ID: Date: Tue, 7 May 2024 10:39:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/6] mm: introduce pte_move_swp_offset() helper which can move offset bidirectionally Content-Language: en-GB To: Barry Song <21cnbao@gmail.com> Cc: David Hildenbrand , akpm@linux-foundation.org, linux-mm@kvack.org, baolin.wang@linux.alibaba.com, chrisl@kernel.org, hanchuanhua@oppo.com, hannes@cmpxchg.org, hughd@google.com, kasong@tencent.com, linux-kernel@vger.kernel.org, surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yosryahmed@google.com, yuzhao@google.com, ziy@nvidia.com References: <20240503005023.174597-1-21cnbao@gmail.com> <20240503005023.174597-4-21cnbao@gmail.com> <7548e30c-d56a-4a57-ab87-86c9c8e523b1@arm.com> <0d20d8af-e480-4eb8-8606-1e486b13fd7e@redhat.com> <0bca057d-7344-40a6-a981-9a7a9347a19f@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 92673160012 X-Stat-Signature: ot5kntghf7b35cyqxf3x3mpwj5dxbb5t X-Rspam-User: X-HE-Tag: 1715074795-733520 X-HE-Meta: U2FsdGVkX1/ERU90EkkglmxcErZNwS5vVcUYSY9yyW+ieiqYXK/2lznUs4nP5RPfhHjnY2jmkqtPvoNUZrG2hNL2SXnkdJvcq7sQJClF8L/bQEy78i0nRQ3X1O3CMx88XtcwGXKkN0nPOueZV8uywMc27gsrLi+rgkl/tD0ZFjuwGRZDvh4Xzu4DM9+bgNzlzDGIh2VrSn2SQfSfLyiEjcAedKnkok051YVoEffyQjbp50R9m+5ck+6v5YUMpmy+hGg+cFV9ZiecQYXiF4arCMX7P7cnEndAEK2+T/bKIxxQKw9aDjdwmz9jmpfbmhwe540DqUH0SYBDlcalyjhWM+SIoopy6/FS/dox3cjKBz7sv/8ouVKwpOpl099lky7DE82ns8K84tbSFB+LF8uhvHVrIplCjqY67bnClxC2NZohZfkRq9QZaXlVvjgjyRziCZSwL4eUfzJ33QGIxOfPxVIaSPY9i50Ln+IHIoTjV0ZjkcEJlxj9MOW3GLrdIGM3jm2CzlmttKE+k/eW+Fwu0nSdjfQbxykib3BVNqbJ8x4o/drNSci6BoGK8RylACNXqu2rQ5PKhpxsQX8Ju3x+qa5hHMBBewhx8jnPcKSYh6Giqli2cpun402wFgiBtDGw/q+zohbgEKlF6nA6CJWgpJto+ACErdoM7VYnSIe76NsdyAW+RT8Ano2im+BHAVb7bB/PchX0ACiCEt4PqxE3CjE/7TrKblTGvo6QrfR3oOz5bRbgDYaYdF3ZJs/5FRieB6HRfLR5/T5oYsmNRO3pYuTzA72LWEw2cr/YxwHleltQ6eHMjMy4vWuYX93vE9MaHg4vDaNAWtMZ4bRv0iqmzs+ILv+TBj1ZKUOSofrCwzxi9O61HFpHv7TynSTAaH/bpQqw5i7fBbRinpIXApRhD5MQ9oSfszvFL+uEuggK2EDVEAphtpdfodPGrtibpSU2n30/BDEsCHcMYMIle2P DU1kuKma 1csKQaRaeQ/I4OavH30M9AC+9nDet4oWboszxHcEeWIeXM6uIw7SEhnWGAlxya87uZCd8VQppQCsYnAOZdsLc1kVfIM5B0AZD3cMhvLER53XeRNQgAcbCPWf9rN7AK6CbSNc93pe5WOFy1vbyxHiI5cd9+vdS1xhKrCLUJIgqDfv/ZSgx/QG1SdXRXbfI1wCZsg293W8yllIBWkGfTTN9GuyzDishiLBl4ouNboILSik7qWAGlLD+KVjgEsgoxuPwS/z6WZgGX7gVvat944o8p7R2wD4ZJOsgRbdOfwzP4yzinJwvehoPUXW7vwn8L8T8SMtYTSUTN9X+G7bo+FgKDehunvRIwUTb1F4kfu3wOGBhNOhta0mid9NxaGTQMW9yxf9SIu94ZCkk6fVlrnWyKFVxQYyDmTP89xs3gUTJ4AJOBXeCygOE+CZVxEUDsZlPL30m 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 07/05/2024 09:24, Barry Song wrote: > On Tue, May 7, 2024 at 8:14 PM Ryan Roberts wrote: >> >> On 06/05/2024 09:31, David Hildenbrand wrote: >>> On 06.05.24 10:20, Barry Song wrote: >>>> On Mon, May 6, 2024 at 8:06 PM David Hildenbrand wrote: >>>>> >>>>> On 04.05.24 01:40, Barry Song wrote: >>>>>> On Fri, May 3, 2024 at 5:41 PM Ryan Roberts wrote: >>>>>>> >>>>>>> On 03/05/2024 01:50, Barry Song wrote: >>>>>>>> From: Barry Song >>>>>>>> >>>>>>>> There could arise a necessity to obtain the first pte_t from a swap >>>>>>>> pte_t located in the middle. For instance, this may occur within the >>>>>>>> context of do_swap_page(), where a page fault can potentially occur in >>>>>>>> any PTE of a large folio. To address this, the following patch introduces >>>>>>>> pte_move_swp_offset(), a function capable of bidirectional movement by >>>>>>>> a specified delta argument. Consequently, pte_increment_swp_offset() >>>>>>> >>>>>>> You mean pte_next_swp_offset()? >>>>>> >>>>>> yes. >>>>>> >>>>>>> >>>>>>>> will directly invoke it with delta = 1. >>>>>>>> >>>>>>>> Suggested-by: "Huang, Ying" >>>>>>>> Signed-off-by: Barry Song >>>>>>>> --- >>>>>>>> mm/internal.h | 25 +++++++++++++++++++++---- >>>>>>>> 1 file changed, 21 insertions(+), 4 deletions(-) >>>>>>>> >>>>>>>> diff --git a/mm/internal.h b/mm/internal.h >>>>>>>> index c5552d35d995..cfe4aed66a5c 100644 >>>>>>>> --- a/mm/internal.h >>>>>>>> +++ b/mm/internal.h >>>>>>>> @@ -211,18 +211,21 @@ static inline int folio_pte_batch(struct folio >>>>>>>> *folio, unsigned long addr, >>>>>>>> } >>>>>>>> >>>>>>>> /** >>>>>>>> - * pte_next_swp_offset - Increment the swap entry offset field of a swap >>>>>>>> pte. >>>>>>>> + * pte_move_swp_offset - Move the swap entry offset field of a swap pte >>>>>>>> + * forward or backward by delta >>>>>>>> * @pte: The initial pte state; is_swap_pte(pte) must be true and >>>>>>>> * non_swap_entry() must be false. >>>>>>>> + * @delta: The direction and the offset we are moving; forward if delta >>>>>>>> + * is positive; backward if delta is negative >>>>>>>> * >>>>>>>> - * Increments the swap offset, while maintaining all other fields, including >>>>>>>> + * Moves the swap offset, while maintaining all other fields, including >>>>>>>> * swap type, and any swp pte bits. The resulting pte is returned. >>>>>>>> */ >>>>>>>> -static inline pte_t pte_next_swp_offset(pte_t pte) >>>>>>>> +static inline pte_t pte_move_swp_offset(pte_t pte, long delta) >>>>>>> >>>>>>> We have equivalent functions for pfn: >>>>>>> >>>>>>> pte_next_pfn() >>>>>>> pte_advance_pfn() >>>>>>> >>>>>>> Although the latter takes an unsigned long and only moves forward currently. I >>>>>>> wonder if it makes sense to have their naming and semantics match? i.e. change >>>>>>> pte_advance_pfn() to pte_move_pfn() and let it move backwards too. >>>>>>> >>>>>>> I guess we don't have a need for that and it adds more churn. >>>>>> >>>>>> we might have a need in the below case. >>>>>> A forks B, then A and B share large folios. B unmap/exit, then large >>>>>> folios of process >>>>>> A become single-mapped. >>>>>> Right now, while writing A's folios, we are CoWing A's large folios >>>>>> into many small >>>>>> folios. I believe we can reuse the entire large folios instead of doing >>>>>> nr_pages >>>>>> CoW and page faults. >>>>>> In this case, we might want to get the first PTE from vmf->pte. >>>>> >>>>> Once we have COW reuse for large folios in place (I think you know that >>>>> I am working on that), it might make sense to "COW-reuse around", >>>> >>>> TBH, I don't know if you are working on that. please Cc me next time :-) >>> >>> I could have sworn I mentioned it to you already :) >>> >>> See >>> >>> https://lore.kernel.org/linux-mm/a9922f58-8129-4f15-b160-e0ace581bcbe@redhat.com/T/ >>> >>> I'll follow-up on that soonish (now that batching is upstream and the large >>> mapcount is on its way upstream). >>> >>>> >>>>> meaning we look if some neighboring PTEs map the same large folio and >>>>> map them writable as well. But if it's really worth it, increasing page >>>>> fault latency, is to be decided separately. >>>> >>>> On the other hand, we eliminate latency for the remaining nr_pages - 1 PTEs. >>>> Perhaps we can discover a more cost-effective method to signify that a large >>>> folio is probably singly mapped? >>> >>> Yes, precisely what I am up to! >>> >>>> and only call "multi-PTEs" reuse while that >>>> condition is true in PF and avoid increasing latency always? >>> >>> I'm thinking along those lines: >>> >>> If we detect that it's exclusive, we can certainly mapped the current PTE >>> writable. Then, we can decide how much (and if) we want to fault-around writable >>> as an optimization. >>> >>> For smallish large folios, it might make sense to try faulting around most of >>> the folio. >>> >>> For large large folios (e.g., PTE-mapped 2MiB THP and bigger), we might not want >>> to fault around the whole thing -- especially if there is little benefit to be >>> had from contig-pte bits. >>> >>>> >>>>> >>>>> >>>>>> >>>>>> Another case, might be >>>>>> A forks B, and we write either A or B, we might CoW an entire large >>>>>> folios instead >>>>>> CoWing nr_pages small folios. >>>>>> >>>>>> case 1 seems more useful, I might have a go after some days. then we might >>>>>> see pte_move_pfn(). >>>>> pte_move_pfn() does sound odd to me. >> >> Yes, I agree the name is odd. pte_move_swp_offset() sounds similarly odd tbh. >> Perhaps just pte_advance_swp_offset() with a negative value is clearer about >> what its doing? >> > > I am not a native speaker. but dictionary says > > advance: > move forward in a purposeful way. > a forward movement. > > Now we are moving backward or forward :-) Sure, but if you pass a negative value then you are moving forwards by a negative amount ;-) Anyway, forget I said anything - its not important. > >>>>> It might not be required to >>>>> implement the optimization described above. (it's easier to simply read >>>>> another PTE, check if it maps the same large folio, and to batch from there) >> >> Yes agreed. >> >>>>> >>>> >>>> It appears that your proposal suggests potential reusability as follows: if we >>>> have a large folio containing 16 PTEs, you might consider reusing only 4 by >>>> examining PTEs "around" but not necessarily all 16 PTEs. please correct me >>>> if my understanding is wrong. >>>> >>>> Initially, my idea was to obtain the first PTE using pte_move_pfn() and then >>>> utilize folio_pte_batch() with the first PTE as arguments to ensure consistency >>>> in nr_pages, thus enabling complete reuse of the whole folio. >>> >>> Simply doing an vm_normal_folio(pte - X) == folio and then trying to batch from >>> there might be easier and cleaner. >>> >>