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 4A793C02198 for ; Wed, 12 Feb 2025 18:17:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D118E6B0085; Wed, 12 Feb 2025 13:17:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CC2B46B0089; Wed, 12 Feb 2025 13:17:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B89EC6B008A; Wed, 12 Feb 2025 13:17:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 9B60D6B0085 for ; Wed, 12 Feb 2025 13:17:14 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2B067804D3 for ; Wed, 12 Feb 2025 18:17:14 +0000 (UTC) X-FDA: 83112099588.24.A89B0C6 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf13.hostedemail.com (Postfix) with ESMTP id B83D420004 for ; Wed, 12 Feb 2025 18:17:11 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ZqHBJqx3; spf=pass (imf13.hostedemail.com: domain of npache@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=npache@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739384232; 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:dkim-signature; bh=BxMveRKFz79cLdG4IH3t2o0E/2y0nocVQjmWDPhVhkA=; b=wbxoDI/KmQEw+QKdX2D5fghZJSY8W7atUFY9XiQ+6WvWCwaaYPNn23xX1sBTjK4wAq6Tn8 UlaBPXt06NFchyWIPKd3/yHfHTiDQA1mi7jBOErW8786aOdrZn8kGH3Jk56YDDZmjOKO5i cFOPGzniZiDj9gLQ9UyqxOPTHk7fnFI= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ZqHBJqx3; spf=pass (imf13.hostedemail.com: domain of npache@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=npache@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739384232; a=rsa-sha256; cv=none; b=yqsTpQRVT8OCtJEAeO3+5gIUFiyXvZEe8+2OrlYeE44mpvlLqlJ3B+7B7073MmVfLFWA0n PAGJ4BDGj6puKKZ5VdSECiSyrNfw8yEztCmPEOkx1zS471bUW1uiMdh26OqMNrinW6yCsf +VRl1ljqJrbawmA2ueiSQm5cWo0r4v4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739384231; h=from:from: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=BxMveRKFz79cLdG4IH3t2o0E/2y0nocVQjmWDPhVhkA=; b=ZqHBJqx3VRolbWjRI2w5RP1FomQr5oxvxysP1b4/zkmq5ONNqsSu5BwXjLiwij3pLMzdcW g+Pmzay+X3EjVh0oMdTjgCnVCdLZ6wdq7ItoUctKYVNkvBZWG7BB73sWbypebX2ZxRaBPU IlXvCH9bOSDCzEVHLYampR7f23MxcLE= Received: from mail-yb1-f197.google.com (mail-yb1-f197.google.com [209.85.219.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-479-NRbUA0ufPIiGzyw6RwEXqg-1; Wed, 12 Feb 2025 13:17:09 -0500 X-MC-Unique: NRbUA0ufPIiGzyw6RwEXqg-1 X-Mimecast-MFC-AGG-ID: NRbUA0ufPIiGzyw6RwEXqg Received: by mail-yb1-f197.google.com with SMTP id 3f1490d57ef6-e3a1bc0c875so30966276.2 for ; Wed, 12 Feb 2025 10:17:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739384229; x=1739989029; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BxMveRKFz79cLdG4IH3t2o0E/2y0nocVQjmWDPhVhkA=; b=r/PXIRIIUSWuCcLnp0qSyfoH3BtpxGSlneT6B7qrQ8pjfprO0cBJJjg+AFphXOWoIX qej8TmejVRT97tXXF46EHtosJk+SUlCzD/U96qmeRd5WBWhoBkHSXt3V2oFo5Fvw5yT2 oGJMhYCuN3YXisMkrrNpQafAsErhOs4kIYarFkPEUKpTwynkZ1QQQ15s8VQNAelwbRaP XCcqvREXHIuy4AxzD/YsWJRPGoA/uOW6elYslmMaVu3OQNaYhR41pZ6lfGT0wqHAQgol kFuo6VjVYyvs2rUYdrdJDMyVto2rpXuEqa1JzNwcb/Mte579e5Yb2qPZjt84wzbUkieZ MosA== X-Forwarded-Encrypted: i=1; AJvYcCXhspGyTkW1y1PzJmJ+iz0p8+6/Zqx7a2CeaXyopQ1Cuc/ywFoVUANVKCV6B/P8umAvVfFmUl8ZtQ==@kvack.org X-Gm-Message-State: AOJu0Yzs7m6bdOkhB0OGqfeoTm5bEHdpud00pDbr4EdttsuSbMR82I7h Ww1SDikopOShQaCM5qMlRY8e7Xvwmo6cQ06PuOeXxgk6ektWzxSoKu//d2uRAkS7N0b6f8YT9PJ 18glsAb5w0wZ2jVuFjQpgHnIZVAXlGSfceo/iRnQiR7i6f5qtR4fIg9RoxA9PGeVs+RY2l0gZdK kKuMEHpPyKuBZUgNW7AEayTVU= X-Gm-Gg: ASbGncstnz7gUsz2D2KrPzEuYUGp4Jqw5wPzt8s8BBbQM5Jpqom/MTqk62UfdDeTxcD quVXnd3otScEk4SIHp8zZ3+Mv+B9ozUTuinhd6ZPQxxZGq1qjc7o1kjt6x2/Y7vyetNJRvbhxRZ g= X-Received: by 2002:a05:6902:723:b0:e5d:92ad:8e75 with SMTP id 3f1490d57ef6-e5d9f0cc9bamr4474881276.10.1739384229305; Wed, 12 Feb 2025 10:17:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IFmRWNmGPvTL92tISaSvzmzQRtTZjsAvB2xwfv4LnOVPEt2eDN8nv36YnRCgcFOENrQ+VKt/6e+xrukc/dlMKU= X-Received: by 2002:a05:6902:723:b0:e5d:92ad:8e75 with SMTP id 3f1490d57ef6-e5d9f0cc9bamr4474848276.10.1739384228926; Wed, 12 Feb 2025 10:17:08 -0800 (PST) MIME-Version: 1.0 References: <20250211003028.213461-1-npache@redhat.com> <20250211003028.213461-8-npache@redhat.com> <9ade1f26-1642-48b3-b7e4-ba571892c7d6@gmail.com> In-Reply-To: <9ade1f26-1642-48b3-b7e4-ba571892c7d6@gmail.com> From: Nico Pache Date: Wed, 12 Feb 2025 11:16:43 -0700 X-Gm-Features: AWEUYZn2zZJEb98yoS5kTPZnam4dYVVrwTZCheqvi5KbV76ot14n5LicrQs5wd8 Message-ID: Subject: Re: [RFC v2 7/9] khugepaged: add mTHP support To: Usama Arif Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org, ryan.roberts@arm.com, anshuman.khandual@arm.com, catalin.marinas@arm.com, cl@gentwo.org, vbabka@suse.cz, mhocko@suse.com, apopple@nvidia.com, dave.hansen@linux.intel.com, will@kernel.org, baohua@kernel.org, jack@suse.cz, srivatsa@csail.mit.edu, haowenchao22@gmail.com, hughd@google.com, aneesh.kumar@kernel.org, yang@os.amperecomputing.com, peterx@redhat.com, ioworker0@gmail.com, wangkefeng.wang@huawei.com, ziy@nvidia.com, jglisse@google.com, surenb@google.com, vishal.moola@gmail.com, zokeefe@google.com, zhengqi.arch@bytedance.com, jhubbard@nvidia.com, 21cnbao@gmail.com, willy@infradead.org, kirill.shutemov@linux.intel.com, david@redhat.com, aarcange@redhat.com, raquini@redhat.com, dev.jain@arm.com, sunnanyong@huawei.com, audra@redhat.com, akpm@linux-foundation.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, tiwai@suse.de, Johannes Weiner X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: -94JFZesL4Oz0WqVc8U4Iyjv0Gkp2R62bvsHvnx8558_1739384229 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B83D420004 X-Stat-Signature: yex3k4rz5d1xcmaa91ubzwarqqxwkbua X-Rspam-User: X-HE-Tag: 1739384231-368816 X-HE-Meta: U2FsdGVkX1+csxYRWKj4NsGZ7lRNVjrQGaHjE3kMnGMjM6lX/Sve9unPpup424/4aC2IkWQ/JUXafr68ETLzgzM4ayVUKHx6zWX3H10skxnn83x415YPNTpwRfpNyky+V96HMfMM35m+RAQyluDOLiopn5D3HaXhiMR8jbI9RLud8eShGHW6+5FrA5oT93t8GILUjIWmWuJVcr+T7s9Q0t541eZPLBI9RPdhOVZyZRs5ew3TpP3k82T2JCdNKZs9hM83ELBzG25CpVwAcle47QDjsxjKLrP/sKKD5VWi7UW2oFP6Vixm5avKF2/bvRG+3MHDiI8yTim7ICvJ3hNRq9HmLgZNgjQTyxWNQIqm5AKEUj+oFkyBvyfKJBk1ltTevHD2CaDvobZ3r223sKpdCxAlHDE5xYrXG+9VDdNdHJk/DwOfmsiPmLrjsipx5Gaw9DQVaD8SGeq/M0h8yzLwSyIXIfr3dB3SI+tO0TadEbr5KcTtnbOHvoz0EniegERfqno5cYSHyBMsAFMzyRJrjDepbSVsLSmZXWXm7UVwZAIV8kDLdOhtHPu6SCMFed57KH4ERYAewrvz6dEATBmzCqxvX2YvsMHZiWLN5l49NAJjtfSQSCypc82tDle5Bn539rjRKY45JyuZyteSmnrX1IPgYf+gRdYPXqV/w1xuWZDC7StfSKR1GgGIAz+nmOgm4h74BJgZSJU9xwrqTwd0F0hU/NlvVTj7O8amPaXMMUZxB0fWMTb9P0XbGHnVDKNJ52ql/B8cadsRGbFsbMcWfQNOrdMUPY/+PImXi/1hul+f3FV1bDu5Wj3ECkrKqcB+Y9Nems/DWIZUprRbkRCBys3ouxIQ2XoB4DEXTziGEh+CEfczGgq5Rs/uEUx1Gly1HatOTB+2eZoXzQahMCS1z1tqmfkMHdMh1nA1YmRcRn6Hn6kLc/nmf9Vu8MuGfgWaHCWTwEFXb8yRv1eoY6s 7NTJFr8d IBmr4Omk2LH74BblOg5wYsDR4rlK5xy+xy/izVqr/abfJU83RGV6HPUSqT6Umi3D5Q2dqENOoZe0m2yd/RyFXqWHtYRSYAGrQIqTGKKLhI+vC+GsKyQ1mZQL9rCuyhxevQ1Ckf2gkrU0moNwGn0NHzXfOXnvgS/2aHw2j1Sovp3E41/do+rYE3Cth4TBCEr2+Q8klJxR6YWBUJqivGbBJBWw2Crm3e9XQMrnYo3WdpTXcOJeqp3SO5p/9xUiJbJ3GU1OG9WK0qeq6ZsWkahPGgL2ZgJES2scEWoMfVmH9WdGXc3XfjdbChsSyQaKq/hLS5cUC1Xi0Vuq3Z+ST588NRQ3Jpcdz7RXQKWYKD9gd3Nb2F9a7egZAMjiaJdQJNNIcChGGF2s8bjU1yBc= 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 Wed, Feb 12, 2025 at 10:04=E2=80=AFAM Usama Arif wrote: > > > > On 11/02/2025 00:30, Nico Pache wrote: > > Introduce the ability for khugepaged to collapse to different mTHP size= s. > > While scanning a PMD range for potential collapse candidates, keep trac= k > > of pages in MIN_MTHP_ORDER chunks via a bitmap. Each bit represents a > > utilized region of order MIN_MTHP_ORDER ptes. We remove the restriction > > of max_ptes_none during the scan phase so we dont bailout early and mis= s > > potential mTHP candidates. > > > > After the scan is complete we will perform binary recursion on the > > bitmap to determine which mTHP size would be most efficient to collapse > > to. max_ptes_none will be scaled by the attempted collapse order to > > determine how full a THP must be to be eligible. > > > > If a mTHP collapse is attempted, but contains swapped out, or shared > > pages, we dont perform the collapse. > > > > Signed-off-by: Nico Pache > > --- > > mm/khugepaged.c | 122 ++++++++++++++++++++++++++++++++---------------- > > 1 file changed, 83 insertions(+), 39 deletions(-) > > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > > index c8048d9ec7fb..cd310989725b 100644 > > --- a/mm/khugepaged.c > > +++ b/mm/khugepaged.c > > @@ -1127,13 +1127,14 @@ static int collapse_huge_page(struct mm_struct = *mm, unsigned long address, > > { > > LIST_HEAD(compound_pagelist); > > pmd_t *pmd, _pmd; > > - pte_t *pte; > > + pte_t *pte, mthp_pte; > > pgtable_t pgtable; > > struct folio *folio; > > spinlock_t *pmd_ptl, *pte_ptl; > > int result =3D SCAN_FAIL; > > struct vm_area_struct *vma; > > struct mmu_notifier_range range; > > + unsigned long _address =3D address + offset * PAGE_SIZE; > > VM_BUG_ON(address & ~HPAGE_PMD_MASK); > > > > /* > > @@ -1148,12 +1149,13 @@ static int collapse_huge_page(struct mm_struct = *mm, unsigned long address, > > *mmap_locked =3D false; > > } > > > > - result =3D alloc_charge_folio(&folio, mm, cc, HPAGE_PMD_ORDER); > > + result =3D alloc_charge_folio(&folio, mm, cc, order); > > if (result !=3D SCAN_SUCCEED) > > goto out_nolock; > > > > mmap_read_lock(mm); > > - result =3D hugepage_vma_revalidate(mm, address, true, &vma, cc, H= PAGE_PMD_ORDER); > > + *mmap_locked =3D true; > > + result =3D hugepage_vma_revalidate(mm, address, true, &vma, cc, o= rder); > > if (result !=3D SCAN_SUCCEED) { > > mmap_read_unlock(mm); > > goto out_nolock; > > @@ -1171,13 +1173,14 @@ static int collapse_huge_page(struct mm_struct = *mm, unsigned long address, > > * released when it fails. So we jump out_nolock directly= in > > * that case. Continuing to collapse causes inconsistenc= y. > > */ > > - result =3D __collapse_huge_page_swapin(mm, vma, address, = pmd, > > - referenced, HPAGE_PMD_ORDER); > > + result =3D __collapse_huge_page_swapin(mm, vma, _address,= pmd, > > + referenced, order); > > if (result !=3D SCAN_SUCCEED) > > goto out_nolock; > > } > > > > mmap_read_unlock(mm); > > + *mmap_locked =3D false; > > /* > > * Prevent all access to pagetables with the exception of > > * gup_fast later handled by the ptep_clear_flush and the VM > > @@ -1187,7 +1190,7 @@ static int collapse_huge_page(struct mm_struct *m= m, unsigned long address, > > * mmap_lock. > > */ > > mmap_write_lock(mm); > > - result =3D hugepage_vma_revalidate(mm, address, true, &vma, cc, H= PAGE_PMD_ORDER); > > + result =3D hugepage_vma_revalidate(mm, address, true, &vma, cc, o= rder); > > if (result !=3D SCAN_SUCCEED) > > goto out_up_write; > > /* check if the pmd is still valid */ > > @@ -1198,11 +1201,12 @@ static int collapse_huge_page(struct mm_struct = *mm, unsigned long address, > > vma_start_write(vma); > > anon_vma_lock_write(vma->anon_vma); > > > > - mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, mm, address, > > - address + HPAGE_PMD_SIZE); > > + mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, mm, _address= , > > + _address + (PAGE_SIZE << order)); > > mmu_notifier_invalidate_range_start(&range); > > > > pmd_ptl =3D pmd_lock(mm, pmd); /* probably unnecessary */ > > + > > /* > > * This removes any huge TLB entry from the CPU so we won't allow > > * huge and small TLB entries for the same virtual address to > > @@ -1216,10 +1220,10 @@ static int collapse_huge_page(struct mm_struct = *mm, unsigned long address, > > mmu_notifier_invalidate_range_end(&range); > > tlb_remove_table_sync_one(); > > > > - pte =3D pte_offset_map_lock(mm, &_pmd, address, &pte_ptl); > > + pte =3D pte_offset_map_lock(mm, &_pmd, _address, &pte_ptl); > > if (pte) { > > - result =3D __collapse_huge_page_isolate(vma, address, pte= , cc, > > - &compound_pagelist, HPAGE_PMD_ORD= ER); > > + result =3D __collapse_huge_page_isolate(vma, _address, pt= e, cc, > > + &compound_pagelist, order); > > spin_unlock(pte_ptl); > > } else { > > result =3D SCAN_PMD_NULL; > > @@ -1248,8 +1252,8 @@ static int collapse_huge_page(struct mm_struct *m= m, unsigned long address, > > anon_vma_unlock_write(vma->anon_vma); > > > > result =3D __collapse_huge_page_copy(pte, folio, pmd, _pmd, > > - vma, address, pte_ptl, > > - &compound_pagelist, HPAGE_PMD_= ORDER); > > + vma, _address, pte_ptl, > > + &compound_pagelist, order); > > pte_unmap(pte); > > if (unlikely(result !=3D SCAN_SUCCEED)) > > goto out_up_write; > > @@ -1260,20 +1264,37 @@ static int collapse_huge_page(struct mm_struct = *mm, unsigned long address, > > * write. > > */ > > __folio_mark_uptodate(folio); > > - pgtable =3D pmd_pgtable(_pmd); > > - > > - _pmd =3D mk_huge_pmd(&folio->page, vma->vm_page_prot); > > - _pmd =3D maybe_pmd_mkwrite(pmd_mkdirty(_pmd), vma); > > - > > - spin_lock(pmd_ptl); > > - BUG_ON(!pmd_none(*pmd)); > > - folio_add_new_anon_rmap(folio, vma, address, RMAP_EXCLUSIVE); > > - folio_add_lru_vma(folio, vma); > > - pgtable_trans_huge_deposit(mm, pmd, pgtable); > > - set_pmd_at(mm, address, pmd, _pmd); > > - update_mmu_cache_pmd(vma, address, pmd); > > - deferred_split_folio(folio, false); > > - spin_unlock(pmd_ptl); > > + if (order =3D=3D HPAGE_PMD_ORDER) { > > + pgtable =3D pmd_pgtable(_pmd); > > + _pmd =3D mk_huge_pmd(&folio->page, vma->vm_page_prot); > > + _pmd =3D maybe_pmd_mkwrite(pmd_mkdirty(_pmd), vma); > > + > > + spin_lock(pmd_ptl); > > + BUG_ON(!pmd_none(*pmd)); > > + folio_add_new_anon_rmap(folio, vma, _address, RMAP_EXCLUS= IVE); > > + folio_add_lru_vma(folio, vma); > > + pgtable_trans_huge_deposit(mm, pmd, pgtable); > > + set_pmd_at(mm, address, pmd, _pmd); > > + update_mmu_cache_pmd(vma, address, pmd); > > + deferred_split_folio(folio, false); > > + spin_unlock(pmd_ptl); > > + } else { //mTHP > > + mthp_pte =3D mk_pte(&folio->page, vma->vm_page_prot); > > + mthp_pte =3D maybe_mkwrite(pte_mkdirty(mthp_pte), vma); > > + > > + spin_lock(pmd_ptl); > > + folio_ref_add(folio, (1 << order) - 1); > > + folio_add_new_anon_rmap(folio, vma, _address, RMAP_EXCLUS= IVE); > > + folio_add_lru_vma(folio, vma); > > + spin_lock(pte_ptl); > > + set_ptes(vma->vm_mm, _address, pte, mthp_pte, (1 << order= )); > > + update_mmu_cache_range(NULL, vma, _address, pte, (1 << or= der)); > > + spin_unlock(pte_ptl); > > + smp_wmb(); /* make pte visible before pmd */ > > + pmd_populate(mm, pmd, pmd_pgtable(_pmd)); > > + deferred_split_folio(folio, false); > > > Hi Nico, > > This patch will have the same issue as the one I pointed out in > https://lore.kernel.org/all/82b9efd1-f2a6-4452-b2ea-6c163e17cdf7@gmail.co= m/ ? Hi Usama, Yes thanks for pointing that out! I'll make sure to remove the deferred_split_folio call. >