From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 730EC389DFF for ; Tue, 12 May 2026 08:59:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778576366; cv=none; b=TOnGp0KjiH+cjF6F7jyCxflyX2M7uDNPDAn4MVr7wvW7VAW5YOiybiiSN8pV570jpfRQldOqDnPn23lAHm3FSP1WD5XaMAYYOh//MzKU64cHTjnXPMzfEgH0VH7CHvl9UcgDsNAyURwKjvS7EwLK1FXqX4t/GYP1eeRcnhI5fNQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778576366; c=relaxed/simple; bh=dyGIFBYBc7vTYuZy6i+a3650vI0jAfmiTjuPo3qSCvE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QbeMPs+ZjWh8quGjFRor3fTZ4bAYh3LDFUa0jsNqtz1LTmFFuocRsrBiA0iQwoTMup+H5213f6sMxkecSFx5BH44qh+wsuAAsgUWq0k4aibbZBdaDI3KakSE5mwFl4GkADiRTmxG/+egbZVVW5XjSV9sIdVmMB7ATPop2HZXE0Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=tqf9cy7q; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="tqf9cy7q" 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 923C315A1; Tue, 12 May 2026 01:59:14 -0700 (PDT) Received: from [10.164.148.42] (MacBook-Pro.blr.arm.com [10.164.148.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 98CE63F7B4; Tue, 12 May 2026 01:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778576359; bh=dyGIFBYBc7vTYuZy6i+a3650vI0jAfmiTjuPo3qSCvE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=tqf9cy7qyK7wO0mURj4OkxuC09qcuxSe/gLANF/trgSU12x7rhxpikRgexN9FVIiB BszJ05RqnUWKAUwmPZsYjPVjb56vYE4QwGKVxKFy0AhPzw2WF1Fy/p2fujmcbzRN5Q 38oQ8d4Ty0PDYDRU54DCIdUaFAyRlQJpifEDJnIY= Message-ID: <31b1ed29-5645-4804-8a3e-8d63abfc291d@arm.com> Date: Tue, 12 May 2026 14:29:08 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 9/9] mm/rmap: enable batch unmapping of anonymous folios To: "David Hildenbrand (Arm)" , akpm@linux-foundation.org, ljs@kernel.org, hughd@google.com, chrisl@kernel.org, kasong@tencent.com Cc: riel@surriel.com, liam@infradead.org, vbabka@kernel.org, harry@kernel.org, jannh@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, rppt@kernel.org, surenb@google.com, mhocko@suse.com, baolin.wang@linux.alibaba.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com, pfalcato@suse.de, ryan.roberts@arm.com, anshuman.khandual@arm.com References: <20260506094504.2588857-1-dev.jain@arm.com> <20260506094504.2588857-10-dev.jain@arm.com> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/05/26 1:46 pm, David Hildenbrand (Arm) wrote: > On 5/6/26 11:45, Dev Jain wrote: >> Enable batch clearing of ptes, and batch swap setting of ptes for anon >> folio unmapping. >> >> Processing all ptes of a large folio in one go helps us batch across >> atomics (add_mm_counter etc), barriers (in the function >> __folio_try_share_anon_rmap), repeated calls to page_vma_mapped_walk(), >> to name a few. In general, batching helps us to execute similar code >> together, making the execution of the program more memory and >> CPU friendly. >> >> On arm64-contpte, batching also helps us avoid redundant ptep_get() calls >> and TLB flushes while breaking the contpte mapping. >> >> The handling of anon-exclusivity is very similar to commit cac1db8c3aad >> ("mm: optimize mprotect() by PTE batching"). Since folio_unmap_pte_batch() >> won't look at the bits of the underlying page, we need to process >> sub-batches of ptes pointing to pages which are same w.r.t exclusivity, >> and batch set only those ptes to swap ptes in one go. Hence export >> page_anon_exclusive_sub_batch() to internal.h and reuse it. >> >> arch_unmap_one() is only defined for sparc64; I am not comfortable >> regarding the nuances between retrieving the pfn from pte_pfn() or from >> (paddr = pte_val(oldpte) & _PAGE_PADDR_4V). >> >> (And, pte_next_pfn() can't even be called from arch_unmap_one() because >> that file does not include pgtable.h) So just disable the >> "sparc64-anon-swapbacked" case for now. >> >> We need to take care of rmap accounting (folio_remove_rmap_ptes) and >> reference accounting (folio_put_refs) when anon folio unmap succeeds. >> In case we partially batch the large folio and fail, we need to correctly >> do the accounting for pages which were successfully unmapped. So, put >> this accounting code in __unmap_anon_folio() itself, instead of doing >> some horrible goto jumping at the callsite of unmap_anon_folio(). >> >> Add a comment at relevant places to say that we are on a device-exclusive >> entry and not a present entry. >> >> If the batch length is less than the number of pages in the folio, then >> we must skip over this batch. >> >> The page_vma_mapped_walk API ensures this - check_pte() will return true >> only if any of [pvmw->pfn, pvmw->pfn + nr_pages) is mapped by the pte. >> There is no pfn underlying a swap pte, so check_pte returns false and we >> keep skipping until we hit a present pte, which is where we want to start >> unmapping from next. >> > > This patch is doing too much. Please separate the cleanups (e.g., moving stuff > into helpers -- that likely should have a ttu_ prefix) from the real deal. Okay. > >