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 AF2C8C25B4F for ; Tue, 7 May 2024 08:14:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 459226B009A; Tue, 7 May 2024 04:14:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 408E16B009B; Tue, 7 May 2024 04:14:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 31F176B009E; Tue, 7 May 2024 04:14:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 146BD6B009A for ; Tue, 7 May 2024 04:14:52 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B261A1407EC for ; Tue, 7 May 2024 08:14:51 +0000 (UTC) X-FDA: 82090888782.09.47A8621 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf02.hostedemail.com (Postfix) with ESMTP id A7EC98000D for ; Tue, 7 May 2024 08:14:49 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715069690; 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=zMOR9StmhhFVzPoXRZbhKCenWwR0qDuovhuEBNXzyu0=; b=UV5s9zK3nu+AXFEo5XUFJbgDyCEmbGUFpsl3nsfFwr1UwWTs3Z5qsYsEcvipWhs5PBlfkx J68Kg1xYuG1FZZKPMMvkAr9Upx42Ran7uo9kiihYqOXIsX8w9ZEf2RU+Ee2reKmodz1L86 Z/sJq30fUPY6a3SuYHN1+GFIkd6c0w0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715069690; a=rsa-sha256; cv=none; b=Oa8GiwYclUGHyneYBtpK/alTVNoStUJhwl1dgT1NsIxlO5kPLCN21ha8IFui3TceG+thWD BwwrCsjt4BZmrJDYgPENS1DE5VGfrHwf3oHSKDJTyVflIHK8NyUcl+9mS6nKTzrSH5R4wB PZGYPV79yJ8s3u9QoFxGsBib+Zow0cE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com 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 9DCBF106F; Tue, 7 May 2024 01:15:14 -0700 (PDT) Received: from [10.57.67.145] (unknown [10.57.67.145]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 152E53F793; Tue, 7 May 2024 01:14:43 -0700 (PDT) Message-ID: <0bca057d-7344-40a6-a981-9a7a9347a19f@arm.com> Date: Tue, 7 May 2024 09:14:41 +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: David Hildenbrand , Barry Song <21cnbao@gmail.com> Cc: 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> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: A7EC98000D X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: gs7i3cgr7ix7yfyhr6zydzchsg8byeyn X-HE-Tag: 1715069689-838467 X-HE-Meta: U2FsdGVkX18QXlIafs4IMLkqn4uDkygSlYoPYvpH7I8wQ6Hn2aGlS4sXML8NWVENeV88K0mgFvS7O+dPRlzBiYQy/mbYPctLGi72honaERYrfR3BR3i78lzlhKIffRNqkZbQk7IPslrqVXB2A1yFvVyLZAduD6bi0rZ/htbYVlUEZh09+qbl2ATDzpsOuPOJnLjUd8ftn9/WMytsobsgzHZYB4u6P/gAdj0DYTpBaA+c3Tk1kmo9bn5rpcL8kTf4aZj27uroOUvNh4bMHu3ui9LpFEdNQDucS9lYYDqsRMqJFJu8x5x33J9kWX9Tl3DgP5qt7tPv3GImOA2VXlOUQhqV0BpUwjRw3nWmAg7x+p2ozCYkpUz/G99dwzIOuKxPNxyq10rUnnDKtbs2QO/Tk0CaucTzQukEFskCZ3jKWMVinLjzzmV/6zgkBAQNIWLjwsFjmLhXuyDHa3n7WyEEko4SyzjzL4mp4/BwWfSKOGT8Xo9elVzB2diX3eTj8jWKDseNMCvZAuIwCSHWiLMfQRcxxbgNj3iC1UIF4ITfvrnVH0PdHbERGMhLugP8/NEs40ESgKBjju2P5EdoR4lzZX5pKp6uaBAm+aIPdyS3O0L7RUXIVV/EcquAPzh9pqO02Rhgb3vyK1TUuW3tJwVvoJ0qROg0wqRkLjJfA8DmndyY5p1SlA23+2S4xDmsb/rNsQAjGGbFlneWK5wDnQ3An+xYmTTUPuTHnD3bxjMjjOUFIJmVjdN9YJe1TgjMp5LgTVYWmapgG7fMpYTECj6CkHHwjqmP5fvkTw7T2MIimXGUrNvWkJQvCzHpAYfKnrNbWW1q2aMIQb8FisO/sOGzEs+kzPEPZQ9TWEPoQThzXbfQw7C+FFMxRx8isBkjJ3KMfAu4zexcW2/5Wgbil65005RBJNVkNwEoGctPLGWfPyNatU3kzlnbsnRtMeKnGG9I6zMG+CtpgXXUJlfSPiN 4LeM3pDW 6irLgq+LEpeWpoKUmxyFtaiJ4PaBZmiBU+t0Bhi4NvRLqXqde05AOb8/SeJGPzmZ6I6xtlbj+XhmCIuhatIWjPHo1ebBZN2wLUdP5d75GFluh8AKWQZGHE+55J5T08gxqLYdvFVY267AFiOS9bU9ZQBGcDdo1j6V9CWh2WhbqakDwQ0AE+ONMi4N/bH8wCvxyijbmF0gvuQ/Cszdm0BBvTC52M0ibEbOrL0qWQ0DHF/qrTc3Yuu6ZAnQIFvd3C2h+Y9KNGpKz3ssP2UEI+SHdMhimFI8BK26+dKKpfktrBMkWzbjdlWP6DzUR0cD6QKTgD74razvTOF2UqahlWaqPGkmuXxEHfFMy2Ul2dPCN+kV0x1p6XGrqwiBZ7HDz777d0jQAgaV4+QgmHp76iGlnXxQXaFDp4Dr7SwUCqGXu1wJOTPXFTOKQaaFDXfJTVYLlHpIi 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 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? >>> 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. >