From patchwork Mon Jul 1 08:46:41 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Qi Zheng X-Patchwork-Id: 13717666 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 DE3A3C2BD09 for ; Mon, 1 Jul 2024 08:48:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 721AB6B00A1; Mon, 1 Jul 2024 04:48:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D1536B00A2; Mon, 1 Jul 2024 04:48:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 572426B00A3; Mon, 1 Jul 2024 04:48:08 -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 39AA16B00A1 for ; Mon, 1 Jul 2024 04:48:08 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E6BE71A1A17 for ; Mon, 1 Jul 2024 08:48:07 +0000 (UTC) X-FDA: 82290556614.13.F093A30 Received: from mail-oa1-f51.google.com (mail-oa1-f51.google.com [209.85.160.51]) by imf29.hostedemail.com (Postfix) with ESMTP id DDDFA12001A for ; Mon, 1 Jul 2024 08:48:05 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=dyMF+q6v; spf=none (imf29.hostedemail.com: domain of zhengqi.arch@bytedance.com has no SPF policy when checking 209.85.160.51) smtp.mailfrom=zhengqi.arch@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719823669; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=frs6IF5FChuIQRpreMojgjHMqoHuIWxIzozpQca1jl0=; b=RrFXLE8Qg8n7roHKvlEqwFgw0LtcuomfvOvRENhkI9N9kJ4BAj56tSjYvrnnH/yHUUsq9+ jQ0k7tKfAKhCL5X+QYQpf09iBy1rwdTEq5DJZEIl2g1CtFThqXcpC27tzaL1+jQRmRLIKF ZkkGtyZbHyaI1lMxwvDC6RUoSC0oopQ= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=dyMF+q6v; spf=none (imf29.hostedemail.com: domain of zhengqi.arch@bytedance.com has no SPF policy when checking 209.85.160.51) smtp.mailfrom=zhengqi.arch@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719823669; a=rsa-sha256; cv=none; b=lu9wCBfXHu1zADNnd9w1td9AEgqrgQzQN0xCNEljwqwu9DuzKQrGUKMcc9yRw4TiWF4qNg lsvtQHBBdjepzk9kGZE/jO0AVl9KlHoM9VtYaFb2+AmGZbwtx9pjtIYizIlNCkxIa9EDVi S7LXAQq+9nyuE+QBImCZKzyhX5LGj1E= Received: by mail-oa1-f51.google.com with SMTP id 586e51a60fabf-25cce249004so441785fac.1 for ; Mon, 01 Jul 2024 01:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1719823685; x=1720428485; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=frs6IF5FChuIQRpreMojgjHMqoHuIWxIzozpQca1jl0=; b=dyMF+q6vOSqywlJkUwktmkWoNeMEVKUleLN0WesgwWVgHxdblw7JewEUDtFwby2RKu IzNJNI1yyTN+OQg1PiWUYGB+XMLr0EcAry+6YKAScN65y1J7i7Y4y58BlH84ZQ3g3EE3 P7wWvi6b/CrlZiB8TKV9voLwdg2+2sfZDrqtE4BFsl7oSZvYfGdXyNLWMblRtO6tte9q AolPTdLRZdHRSE2rPiHZMlZURoiBa2g7LxyS/R8R4vrIBlMr2QTAuLihklh8ARzwjwIF 4VZxrp9sFNrewuVwo5J8+StbFdaSAripZZAzAOveDa1gIUY0Xoh8j95YZvdMILhwu0cU Cm4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719823685; x=1720428485; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=frs6IF5FChuIQRpreMojgjHMqoHuIWxIzozpQca1jl0=; b=uBe8cMrqOsKgbCcbfvSNK0s0ucj7Ezy+yL12HVz/KtG8jSLfI83bK2EOHuJkggMBSB QElCogLlP5gpgF+ik3zONrPYhZAdBQTjl5iPkgGuBhQYcDBzTtaHx98bMEDTYNwO7BDK kZhb0FW6eHcPJ+KdoOJIzE2KqaC7g9Y0ql6W0I3Eh7hTagXE3Jb76/66e+gTauluw/sA 4RMh8Y8y+aC0EtHIOU+D22EKyWFLv1R9wNAFfHgghe0iMVhsmyOlfhWxPE8hHMuuR6Ez oVg3d87UVe1+1fvGnxfjgKpuMBhnTIrpuuv9j/d3s/5yh/jLiO55Fk74rQrSr4Rl9Y80 jvqw== X-Gm-Message-State: AOJu0YynWj5F1fh4HyIEh4iN2CUzFLJjj3Cgc6xqaGu9JJKz8dZTGJCz RqBrveL+/ZrVic5XaXmuP0pz4SFfl/eS5M8wPEcO5pxTVYjGETHlnGEPdvO64UM= X-Google-Smtp-Source: AGHT+IHPVphQRqIO40k0Pi9VpvmEFlcKrx/R+Gbj7SwPvGaCvS/jhgIObiJQSsnIzBruRPyGmuX4Rw== X-Received: by 2002:a05:6871:7806:b0:254:ecbd:1815 with SMTP id 586e51a60fabf-25db3709c91mr5160698fac.5.1719823684561; Mon, 01 Jul 2024 01:48:04 -0700 (PDT) Received: from C02DW0BEMD6R.bytedance.net ([139.177.225.241]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70804a7e7e0sm5932374b3a.204.2024.07.01.01.48.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jul 2024 01:48:04 -0700 (PDT) From: Qi Zheng To: david@redhat.com, hughd@google.com, willy@infradead.org, mgorman@suse.de, muchun.song@linux.dev, akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qi Zheng Subject: [RFC PATCH 0/7] synchronously scan and reclaim empty user PTE pages Date: Mon, 1 Jul 2024 16:46:41 +0800 Message-Id: X-Mailer: git-send-email 2.24.3 (Apple Git-128) MIME-Version: 1.0 X-Stat-Signature: tuqwkkw78e6k8egjj3nkiihfofuypto7 X-Rspam-User: X-Rspamd-Queue-Id: DDDFA12001A X-Rspamd-Server: rspam02 X-HE-Tag: 1719823685-326618 X-HE-Meta: U2FsdGVkX19P/RlNUzlI/uq2y2D0uZ9o6oZwuRVtKf83/5lRiMXMJhzyKnckiuSHSgE6OqVPuW+qElIONDvcCTgW+AUhlm73AC7uzGb88UzJm2wEMtFIlfxLAy1vqqXQvA+lfDICz830breb3S3D7kLlZtoi7MrSejh4gPvykXev7pz/ZPW3NBkLFTBiIjlyPcPWWSQytq05wcRC6veWl2x7u/e/K3fVOi9r1xxqthOUFMalimfAVvw+HAuw/vKxBBblcHpyNaUkt3mo54RNVS21sej1Htnvf3TTYGoZg4O22JTOK3VpWjNJAOMIXu7Su7JVxzDuMaTjoyEYA8G6/obLST/xVgw1sXFlzADQveWmE34qf4RZ6qDy6nmXt1e/uX0DP238nZc9R6uRbyMNo7h7uIPBPnDqs64cx9c8xqLCrOcZJdx8MWh1VDdPgQ8VjFoQQ2kZaL+LkZuwMsjE3tPihRbo021RaPWVdbaqAKWTO+VA0X4S3vwpcJ1AVGokJUf35QHr8BRfcnQ7QQ7W5Tr+MoqBCXmyAuAYeXejNsuHSIKI0pB1BNyiUUSn6ObGPqbuxKKEr9qGkO1oIr7/1G/sqXv5MYnOBewmkmLUkNTPVqqo3n5R4JSWiyzoM+IZAETECDZFQnThtRN85dYfqAV8gCXCb3k5a04ZtbW0JTYmmk9mGjPDMwOlbjq0ykGPtdnHu9lQKpKv4FgzMZfhPMnDADkbmoOTMCGy68h8C+KpaakwC5xGhSiootUe8oIOrjlKdSmjNkYpSY0bbSx3hMFbOHpefMdWLfYNWgNQUZLxT2f63yV74B7y4tJulu+TyAiiq2RWUSkMZCTdsw/9d0FGjVVF4TnsfaaKZvmGV5A5b1Djq3QhsASG2BGa0Lg1ZNiffIQTdWnyKG8i90bsh/M4G8IN2bQIzItk0oXOTDnThVKCLxw4Fu7xgZ39aSdZxkIDxcdLAS4B0AyjZxO ZrLTc29X ujeEZVXWCJJXs1GmrQi6tXE3uhbav5djc7x6Hryqc6rg8iUytxZtpYvWknQvfXja/YihltaslF+/3Ep33vaCfFSi9Ufqe5qJ8rFwDpK+VkYp11XmTJsa6AMQxpKnYzO9Xnzd/+7gl1jk/0Wm0rXa/u7RyeGdGtlB3arAKtMW/sVGCVtrfILv4IsmotUxS1y6pOun/yYG7eIgz52Xv8rGGs8NyxrqFYO1Gnrzj1Erv2Sm+ZtODHt9kRJ91j72lf0G4fklBotQx/QIpK2W4LU3TnLBiCiZk0hA6l9kwO40kJARvv/x6P2fnybub+ta7tV1WR/gnm+NgpSVAP+FakAGaGgWoceRP/n5kRRX5xUgGQIgK7FZtNDDaJUcaOw== 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: Hi all, Previously, we tried to use a completely asynchronous method to reclaim empty user PTE pages [1]. After discussing with David Hildenbrand, we decided to implement synchronous reclaimation in the case of madvise(MADV_DONTNEED) as the first step. So this series aims to synchronously scan and reclaim empty user PTE pages in zap_page_range_single() (madvise(MADV_DONTNEED) etc will invoke this). In zap_page_range_single(), mmu_gather is used to perform batch tlb flushing and page freeing operations. Therefore, if we want to free the empty PTE page in this path, the most natural way is to add it to mmu_gather as well. There are two problems that need to be solved here: 1. Now, if CONFIG_MMU_GATHER_RCU_TABLE_FREE is selected, mmu_gather will free page table pages by semi RCU: - batch table freeing: asynchronous free by RCU - single table freeing: IPI + synchronous free But this is not enough to free the empty PTE page table pages in paths other that munmap and exit_mmap path, because IPI cannot be synchronized with rcu_read_lock() in pte_offset_map{_lock}(). So we should let single table also be freed by RCU like batch table freeing. 2. When we use mmu_gather to batch flush tlb and free PTE pages, the TLB is not flushed before pmd lock is unlocked. This may result in the following two situations: 1) Userland can trigger page fault and fill a huge page, which will cause the existence of small size TLB and huge TLB for the same address. 2) Userland can also trigger page fault and fill a PTE page, which will cause the existence of two small size TLBs, but the PTE page they map are different. For case 1), according to Intel's TLB Application note (317080), some CPUs of x86 do not allow it: ``` If software modifies the paging structures so that the page size used for a 4-KByte range of linear addresses changes, the TLBs may subsequently contain both ordinary and large-page translations for the address range.12 A reference to a linear address in the address range may use either translation. Which of the two translations is used may vary from one execution to another and the choice may be implementation-specific. Software wishing to prevent this uncertainty should not write to a paging- structure entry in a way that would change, for any linear address, both the page size and either the page frame or attributes. It can instead use the following algorithm: first mark the relevant paging-structure entry (e.g., PDE) not present; then invalidate any translations for the affected linear addresses (see Section 5.2); and then modify the relevant paging-structure entry to mark it present and establish translation(s) for the new page size. ``` We can also learn more information from the comments above pmdp_invalidate() in __split_huge_pmd_locked(). For case 2), we can see from the comments above ptep_clear_flush() in wp_page_copy() that this situation is also not allowed. Even without this patch series, madvise(MADV_DONTNEED) can also cause this situation: CPU 0 CPU 1 madvise (MADV_DONTNEED) --> clear pte entry pte_unmap_unlock touch and tlb miss --> set pte entry mmu_gather flush tlb But strangely, I didn't see any relevant fix code, maybe I missed something, or is this guaranteed by userland? Anyway, this series defines the following two functions to be implemented by the architecture. If the architecture does not allow the above two situations, then define these two functions to flush the tlb before set_pmd_at(). - arch_flush_tlb_before_set_huge_page - arch_flush_tlb_before_set_pte_page As a first step, we supported this feature on x86_64 and selectd the newly introduced CONFIG_ARCH_SUPPORTS_PT_RECLAIM. In order to reduce overhead, we only handle the cases with a high probability of generating empty PTE pages, and other cases will be filtered out, such as: - hugetlb vma (unsuitable) - userfaultfd_wp vma (may reinstall the pte entry) - writable private file mapping case (COW-ed anon page is not zapped) - etc For userfaultfd_wp and writable private file mapping cases (and MADV_FREE case, of course), consider scanning and freeing empty PTE pages asynchronously in the future. This series is based on next-20240627. Comments and suggestions are welcome! Thanks, Qi [1]. https://lore.kernel.org/lkml/cover.1718267194.git.zhengqi.arch@bytedance.com/ Qi Zheng (7): mm: pgtable: make pte_offset_map_nolock() return pmdval mm: introduce CONFIG_PT_RECLAIM mm: pass address information to pmd_install() mm: pgtable: try to reclaim empty PTE pages in zap_page_range_single() x86: mm: free page table pages by RCU instead of semi RCU x86: mm: define arch_flush_tlb_before_set_huge_page x86: select ARCH_SUPPORTS_PT_RECLAIM if X86_64 Documentation/mm/split_page_table_lock.rst | 3 +- arch/arm/mm/fault-armv.c | 2 +- arch/powerpc/mm/pgtable.c | 2 +- arch/x86/Kconfig | 1 + arch/x86/include/asm/pgtable.h | 6 + arch/x86/include/asm/tlb.h | 23 ++++ arch/x86/kernel/paravirt.c | 7 ++ arch/x86/mm/pgtable.c | 15 ++- include/linux/hugetlb.h | 2 +- include/linux/mm.h | 13 +- include/linux/pgtable.h | 14 +++ mm/Kconfig | 14 +++ mm/Makefile | 1 + mm/debug_vm_pgtable.c | 2 +- mm/filemap.c | 4 +- mm/gup.c | 2 +- mm/huge_memory.c | 3 + mm/internal.h | 17 ++- mm/khugepaged.c | 24 +++- mm/memory.c | 21 ++-- mm/migrate_device.c | 2 +- mm/mmu_gather.c | 2 +- mm/mprotect.c | 8 +- mm/mremap.c | 4 +- mm/page_vma_mapped.c | 2 +- mm/pgtable-generic.c | 21 ++-- mm/pt_reclaim.c | 131 +++++++++++++++++++++ mm/userfaultfd.c | 10 +- mm/vmscan.c | 2 +- 29 files changed, 307 insertions(+), 51 deletions(-) create mode 100644 mm/pt_reclaim.c