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 C4023C83038 for ; Wed, 2 Jul 2025 00:00:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B16C6B00C2; Tue, 1 Jul 2025 20:00:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58AD76B00C3; Tue, 1 Jul 2025 20:00:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49F9C6B00C4; Tue, 1 Jul 2025 20:00:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3461B6B00C2 for ; Tue, 1 Jul 2025 20:00:39 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CBC85124565 for ; Wed, 2 Jul 2025 00:00:38 +0000 (UTC) X-FDA: 83617368156.22.FF3F672 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf04.hostedemail.com (Postfix) with ESMTP id 0C6B640008 for ; Wed, 2 Jul 2025 00:00:34 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SNKrlPBM; spf=pass (imf04.hostedemail.com: domain of npache@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=npache@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751414436; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=iRV/V7cFhUYa8tD8K3MIiuvNW63Wg6JKNzKDRdWMUPk=; b=mG7w3eUzaTR43/bGRCJUHAjXDQgF/qzBypU5UPoIz4KagWHWj3nD8Lg33PdZWpRqMsvs1y 5XZMnjDTFERRT1VBmnGm+kGNI6tLfK2HC5QJ9E1qrTkElpak/IVSYK+40BxjDuExT5EZbJ TWvOo44ofTViAmNHlBmWGpADfuyFIto= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SNKrlPBM; spf=pass (imf04.hostedemail.com: domain of npache@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=npache@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751414436; a=rsa-sha256; cv=none; b=3XnH8GDpBDxTGfnFu8cAx4PaRjWY19dB+KItIybkfgJk6heeMpD6hAfELfP5bW0vcnP/mr 10mkP7diVX2oocJ2agUOxqAZxt1P/QSdmwRNSipENUYUFJGcice1v7E2pzWtmkLsIrpzP2 qTrbtK9YQ5C8b2y/0O4YBOhHvLf1J9c= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1751414434; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iRV/V7cFhUYa8tD8K3MIiuvNW63Wg6JKNzKDRdWMUPk=; b=SNKrlPBMtcx4Sns3akmt1rw2pSPhj1CrVI9WWUbgUeVFqQxgrHJRP66fZGT48WioLSY72Q zhNaMuo5UjJwDCI+f6IxEjgUZ2mjvUausakHTtYTEjTb+VTM2TF3gxDHXYZ4hI99bQqxfg NH5yoZPYfxweyKIaBY4PHDfBe3Z/oJs= Received: from mail-yw1-f199.google.com (mail-yw1-f199.google.com [209.85.128.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-580-oawj4e5hNa6Yrud6Czie3Q-1; Tue, 01 Jul 2025 20:00:33 -0400 X-MC-Unique: oawj4e5hNa6Yrud6Czie3Q-1 X-Mimecast-MFC-AGG-ID: oawj4e5hNa6Yrud6Czie3Q_1751414433 Received: by mail-yw1-f199.google.com with SMTP id 00721157ae682-70e2b627b47so86407077b3.2 for ; Tue, 01 Jul 2025 17:00:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751414432; x=1752019232; h=content-transfer-encoding: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=iRV/V7cFhUYa8tD8K3MIiuvNW63Wg6JKNzKDRdWMUPk=; b=aKHm+eqQNznx2oGhYkRtmATBHaI8m1r+a5iCvFaJIbWddOjuclFouTXMsXyF+kmGg2 4qSSl0e+3BWtcvfEGZbStI5bDOuRZGbH/GEG/nf02srXEWzkkgTLZ2x9b80AOWCHLGG1 kMChpne8u9qb0QvL6nqCEk+oGlLXvAnAGez+R58TAHBuK0ZXzME/XNUr+/q30QK/qbdt Br3jUv4UpVrVPh93QY9mTghQO/DFnROdnL7cOIiTw2PuTVVSKdDbA2zmEIbIn4P9sF/k eSlGzBn6bcbZdeQpdWITRYX8y2xf4peXU+FkuAqJIaHEo1BYCrGqAt1u+56eDItuuBWI aA7Q== X-Forwarded-Encrypted: i=1; AJvYcCX2YrS3I+rHN2M1NrrVPI17crZluXXQZya7wHLoM4+o73mR1dKNGsDO5O90sbr4eSXDr6QuBKUyBA==@kvack.org X-Gm-Message-State: AOJu0Yzc+w67aiTJCHDzyl19L/ddJ3mfHIz4Akz2U95OX80cfvoTBr8x njCPIpyWTy0XLjifh8J/btWNkyIUWL9PGS3roaMKnKo/mP7/WPotru6AiGyMOweaqDJYVgf+TUl VHJNZnKt0TuVO0KcKDeAIRvgtWz2M71IuDNyDNH8yApsfs1Iv3OBntgtdKe9pwSmnXllnb3IFid 9/imozvfAS2fFa0oJpFaLa9PTj1jk= X-Gm-Gg: ASbGnctoh0az0851VQAbpPm1g++nPZvdMGy38Fw8Kq0p+aDPZJK34i+aeOBlUbuS0u6 mVLJ7T8EkonCvcvL0dfhtJ1JD6eYCJwxl/aC7C9TEVY+RZ79mJUOZdJABZ148WQuRam8VvNKq/Q jZz5ZY6Q== X-Received: by 2002:a05:690c:3705:b0:710:e7ad:9d52 with SMTP id 00721157ae682-7164d3f5e16mr8757937b3.14.1751414432476; Tue, 01 Jul 2025 17:00:32 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHgMkMqenRVIqOB+9ikiw2xzUobWJPDfSpX1sjEEG6ud3M1WjTpVzhUCF5ZRpdsrBnIkVoZFbtg+0UBjBNvEbE= X-Received: by 2002:a05:690c:3705:b0:710:e7ad:9d52 with SMTP id 00721157ae682-7164d3f5e16mr8757197b3.14.1751414431864; Tue, 01 Jul 2025 17:00:31 -0700 (PDT) MIME-Version: 1.0 References: <20250515032226.128900-1-npache@redhat.com> <20250515032226.128900-3-npache@redhat.com> In-Reply-To: From: Nico Pache Date: Tue, 1 Jul 2025 18:00:05 -0600 X-Gm-Features: Ac12FXxAB8ippf1H8C0DLIPh7P_mnejfYCanz9QqAu4hJw7WwvZREJy6H5AGBg4 Message-ID: Subject: Re: [PATCH v7 02/12] introduce khugepaged_collapse_single_pmd to unify khugepaged and madvise_collapse To: "Liam R. Howlett" , Nico Pache , linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, david@redhat.com, ziy@nvidia.com, baolin.wang@linux.alibaba.com, lorenzo.stoakes@oracle.com, ryan.roberts@arm.com, dev.jain@arm.com, corbet@lwn.net, rostedt@goodmis.org, mhiramat@kernel.org, mathieu.desnoyers@efficios.com, akpm@linux-foundation.org, baohua@kernel.org, willy@infradead.org, peterx@redhat.com, wangkefeng.wang@huawei.com, usamaarif642@gmail.com, sunnanyong@huawei.com, vishal.moola@gmail.com, thomas.hellstrom@linux.intel.com, yang@os.amperecomputing.com, kirill.shutemov@linux.intel.com, aarcange@redhat.com, raquini@redhat.com, anshuman.khandual@arm.com, catalin.marinas@arm.com, tiwai@suse.de, will@kernel.org, dave.hansen@linux.intel.com, jack@suse.cz, cl@gentwo.org, jglisse@google.com, surenb@google.com, zokeefe@google.com, hannes@cmpxchg.org, rientjes@google.com, mhocko@suse.com, rdunlap@infradead.org X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: XOK3fK8N9iRSldNroYfsaq4_SE4MetQo3L9t31eFVz8_1751414433 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0C6B640008 X-Stat-Signature: qg8r5qw6ikgjt6ugnnekc4553i81b36y X-HE-Tag: 1751414434-981588 X-HE-Meta: U2FsdGVkX18dqzwrOqVnrYG36jYPN8kW67h2D7XOgg4GuDyRqPW0iRyUkKTGGJZq786FiPWyBMOc9q1Gznb/kr4iPcQulzbNmyG5+k8rVB/oklRM3/TsWX5vXsplMPQycw1hpuvZmc6INzSXJXQ9cAENF4jRcAU1PAuFMGXZ4kGvZff5I+WjepVPpL2lEffUKIvw+CfXmdYtRevl2BNWg2MCkvhG+R8AKdTP1IeSNrv5DtMOSKpdgl2jrBKx6R4fv+IWqZ0G8x1Se0mQMGtSxTR6E2EuGZOQiwxz9oebsDEcc4phGU6zMDQ7ZzldB24U63kCFrL4EJ3dER8A/TqY7qZZgk1MMVU6pgwtDnLy0+gvBADqhwExLvUzfWx6XN/488C+69iDhyRmj3fsB/tvCdLPP3wAIwFnpq5kifh7jXZSgZxoku6wRrPJ2z1eeAxIcgPBc4RxnGj1YntTx27RmuxAocUpav4+ti7bwyRZaCKrNeOrQTIkxOGZDlPwUkV4inLV1d/B9LR5bgMQaFBOqqVNkghTE/XKWZLwfDe/Jddez2jZKhtPpvTmT/KKjbwgqMVmiPw9wtpinF2Uxlgnx+cDi/7Nvi2+nfDmcVORkWoO0GAbgAgFLqV+b8L0HbR3gmrYUNv4tMrS8kv5ciaseoOAhVdpEw/lwpkJJv48aeOn8pN/uyEUXx0krGkKSPT73OBUvWDK9ARnq4s206KVtvDTZNd1s2NqFNuEtJQ0UnABBf6caOFNV0VIUO2QyXKEEdSdPwQB7ZEdR6NIde8VDx7hvPf9Xui0d4h2lnNxLIUsZ5wjEX/eBha4FlkNrZ4/kPIEpkzducgLeBqkHfes4V+IoZV3f4aNa88GkA6EPCVkMBoYmvPd5Lu7AcrxrGS7FJUEJ9AYMR6gc5Q9Sc+0TqWMJ/M1f+HL8u7ltzaIAlP9tj3Xk3symmN5XF0Q6jwMTTZbVNEq8CkMDUcd7+F hqBXH89v QmgxWRB/BfwvuitAU+sWAXx6aK3L4q4gKeLKQKEx/GuFtmc9SdYiCj/YcWttnlCsSYHLbKMoEl8L4xns14RAQWnhQuOxZLGIQ0GRCE0jb8ONjW/ZQHJoqRmHCy62C20NE/keC0tH8I1rQ40Mm1eiNSnqdoCxJxp/B2qoCOZLEnHgIWQnuIfZnQ5cobDmrdLEtDFuR1w54TT4pdWqyCwDWpizelWs6jJTe37hkeNIclg8HXzyjRB7qnun6fJhdeto5sKYYSucv3+N7/yduJFVGOgHLXLJVEEfy0eOFkawImPHZlFXhiawaF8Ugrb2NLE6NceuJ35B4d0/2LbhgC/T/1lkexgBqEKjtZzKrlYWrsU1wLtvoQPbCIILpGjfaH+hV5oneunwqnG9V0pMdFVpKBv5V2Q== 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 Fri, May 16, 2025 at 11:13=E2=80=AFAM Liam R. Howlett wrote: > > * Nico Pache [250514 23:23]: > > The khugepaged daemon and madvise_collapse have two different > > implementations that do almost the same thing. > > > > Create khugepaged_collapse_single_pmd to increase code > > reuse and create an entry point for future khugepaged changes. > > > > Refactor madvise_collapse and khugepaged_scan_mm_slot to use > > the new khugepaged_collapse_single_pmd function. > > > > Reviewed-by: Baolin Wang > > Signed-off-by: Nico Pache > > --- > > mm/khugepaged.c | 96 +++++++++++++++++++++++++------------------------ > > 1 file changed, 49 insertions(+), 47 deletions(-) > > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > > index 806bcd8c5185..5457571d505a 100644 > > --- a/mm/khugepaged.c > > +++ b/mm/khugepaged.c > > @@ -2353,6 +2353,48 @@ static int khugepaged_scan_file(struct mm_struct= *mm, unsigned long addr, > > return result; > > } > > > > +/* > > + * Try to collapse a single PMD starting at a PMD aligned addr, and re= turn > > + * the results. > > + */ > > +static int khugepaged_collapse_single_pmd(unsigned long addr, > > + struct vm_area_struct *vma, bool *mmap= _locked, > > + struct collapse_control *cc) > > +{ > > + int result =3D SCAN_FAIL; > > + struct mm_struct *mm =3D vma->vm_mm; > > + > > + if (IS_ENABLED(CONFIG_SHMEM) && !vma_is_anonymous(vma)) { > > why IS_ENABLED(CONFIG_SHMEM) here, it seems new? Fixed in the next version. It was a mishandled rebase conflict. > > > + struct file *file =3D get_file(vma->vm_file); > > + pgoff_t pgoff =3D linear_page_index(vma, addr); > > + > > + mmap_read_unlock(mm); > > + *mmap_locked =3D false; > > + result =3D khugepaged_scan_file(mm, addr, file, pgoff, cc= ); > > + fput(file); > > + if (result =3D=3D SCAN_PTE_MAPPED_HUGEPAGE) { > > + mmap_read_lock(mm); > > + *mmap_locked =3D true; > > + if (khugepaged_test_exit_or_disable(mm)) { > > + result =3D SCAN_ANY_PROCESS; > > + goto end; > > + } > > + result =3D collapse_pte_mapped_thp(mm, addr, > > + !cc->is_khugepag= ed); > > + if (result =3D=3D SCAN_PMD_MAPPED) > > + result =3D SCAN_SUCCEED; > > + mmap_read_unlock(mm); > > + *mmap_locked =3D false; > > + } > > + } else { > > + result =3D khugepaged_scan_pmd(mm, vma, addr, mmap_locked= , cc); > > + } > > + if (cc->is_khugepaged && result =3D=3D SCAN_SUCCEED) > > + ++khugepaged_pages_collapsed; > > +end: > > + return result; > > This function can return with mmap_read_locked or unlocked.. > > > +} > > + > > static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *r= esult, > > struct collapse_control *cc) > > __releases(&khugepaged_mm_lock) > > @@ -2427,34 +2469,12 @@ static unsigned int khugepaged_scan_mm_slot(uns= igned int pages, int *result, > > VM_BUG_ON(khugepaged_scan.address < hstart || > > khugepaged_scan.address + HPAGE_PMD_SIZ= E > > > hend); > > - if (!vma_is_anonymous(vma)) { > > - struct file *file =3D get_file(vma->vm_fi= le); > > - pgoff_t pgoff =3D linear_page_index(vma, > > - khugepaged_scan.address); > > - > > - mmap_read_unlock(mm); > > - mmap_locked =3D false; > > - *result =3D hpage_collapse_scan_file(mm, > > - khugepaged_scan.address, file, pg= off, cc); > > - fput(file); > > - if (*result =3D=3D SCAN_PTE_MAPPED_HUGEPA= GE) { > > - mmap_read_lock(mm); > > - if (hpage_collapse_test_exit_or_d= isable(mm)) > > - goto breakouterloop; > > - *result =3D collapse_pte_mapped_t= hp(mm, > > - khugepaged_scan.address, = false); > > - if (*result =3D=3D SCAN_PMD_MAPPE= D) > > - *result =3D SCAN_SUCCEED; > > - mmap_read_unlock(mm); > > - } > > - } else { > > - *result =3D hpage_collapse_scan_pmd(mm, v= ma, > > - khugepaged_scan.address, &mmap_lo= cked, cc); > > - } > > - > > - if (*result =3D=3D SCAN_SUCCEED) > > - ++khugepaged_pages_collapsed; > > > > + *ngle_pmd(khugepaged_scan.address, > > + vma, &mmap_locked, cc); > > + /* If we return SCAN_ANY_PROCESS we are holding t= he mmap_lock */ > > But this comment makes it obvious that you know that.. > > > + if (*result =3D=3D SCAN_ANY_PROCESS) > > + goto breakouterloop; > > But later.. > > breakouterloop: > mmap_read_unlock(mm); /* exit_mmap will destroy ptes after this *= / > breakouterloop_mmap_lock: > > > So if you return with SCAN_ANY_PROCESS, we are holding the lock and go > immediately and drop it. This seems unnecessarily complicated and > involves a lock. SCAN_ANY_PROCESS indicates that the process we are working on has either exited, or THPs have been disabled mid-scan. So we have to drop the lock regardless. > > That would leave just the khugepaged_scan_pmd() path with the > unfortunate locking mess - which is a static function and called in one > location.. > > Looking at what happens after the return seems to indicate we could > clean that up as well, sometime later. I see your point, all other instances handle the unlock within their own function and this one should too. instead of handling the unlock in the parent function I should just return with it unlocked and have the already established if(!mmap_locked) do the cleanup. > > > /* move to next address */ > > khugepaged_scan.address +=3D HPAGE_PMD_SIZE; > > progress +=3D HPAGE_PMD_NR; > > @@ -2773,36 +2793,18 @@ int madvise_collapse(struct vm_area_struct *vma= , struct vm_area_struct **prev, > > mmap_assert_locked(mm); > > memset(cc->node_load, 0, sizeof(cc->node_load)); > > nodes_clear(cc->alloc_nmask); > > - if (!vma_is_anonymous(vma)) { > > - struct file *file =3D get_file(vma->vm_file); > > - pgoff_t pgoff =3D linear_page_index(vma, addr); > > > > - mmap_read_unlock(mm); > > - mmap_locked =3D false; > > - result =3D hpage_collapse_scan_file(mm, addr, fil= e, pgoff, > > - cc); > > - fput(file); > > - } else { > > - result =3D hpage_collapse_scan_pmd(mm, vma, addr, > > - &mmap_locked, cc= ); > > - } > > + result =3D khugepaged_collapse_single_pmd(addr, vma, &mma= p_locked, cc); > > + > > if (!mmap_locked) > > *prev =3D NULL; /* Tell caller we dropped mmap_l= ock */ > > > > -handle_result: > > switch (result) { > > case SCAN_SUCCEED: > > case SCAN_PMD_MAPPED: > > ++thps; > > break; > > case SCAN_PTE_MAPPED_HUGEPAGE: > > - BUG_ON(mmap_locked); > > - BUG_ON(*prev); > > - mmap_read_lock(mm); > > - result =3D collapse_pte_mapped_thp(mm, addr, true= ); > > - mmap_read_unlock(mm); > > - goto handle_result; > > All of the above should probably be replaced with a BUG_ON(1) since it's > not expected now? Or at least WARN_ON_ONCE(), but it should be safe to > continue if that's the case. I dont think we should warn as this is the return value for indicating that we are trying to collapse to a mTHP that is smaller than the already established folio (see __collapse_huge_page_isolate), but continuing should be ok. > > It looks like the mmap_locked boolean is used to ensure that *prev is > safe, but we are now dropping the lock and re-acquiring it (and > potentially returning here) with it set to true, so perv will not be set > to NULL like it should. Luckily Lorenzo just cleaned this up with the madvise code changes he made, but yes you are correct. > > I think you can handle this by ensuring that > khugepaged_collapse_single_pmd() returns with mmap_locked false in the > SCAN_ANY_PROCESS case. > > > - /* Whitelisted set of results where continuing OK */ > > This seems worth keeping? I'll add that back, thanks. > > > case SCAN_PMD_NULL: > > case SCAN_PTE_NON_PRESENT: > > case SCAN_PTE_UFFD_WP: > > I guess SCAN_ANY_PROCESS should be handled by the default case > statement? It should probably be added to the switch? I believe it should be handled by the default case, since we dont want to continue, so we break out as intended. > > That is to say, before your change the result would come from either > hpage_collapse_scan_file(), then lead to collapse_pte_mapped_thp() > above. In the khugepaged case we do the following check (khugepaged_test_exit_or_disable) before calling pte_mapped_thp, but we weren't doing it in the madvise_collapse case. seems like we had a bug lingering or unnecessary code in the original implementation (its been that way since day 1). I can note the slight difference in the commit log. I believe having the same check for both is wise, although now I have to ask why we arent using the revalidate function like all other callers do when they drop the lock. I will note this small difference in the commit log, and will invest some time in the future into cleaning up this madness. I think unifying these two callers into one, as I'm trying to do here, will make these behavioral deviations harder in the future, and we can have sanity knowing there is *mostly* one way to call the collapse. > > Now, you can have khugepaged_test_exit_or_disable() happen to return > SCAN_ANY_PROCESS and it will fall through to the default in this switch > statement, which seems like new behaviour? > > At the very least, this information should be added to the git log on > what this patch does - if it's expected? Will do, thanks for the thought provoking review, I had to do some digging to verify this one :) -- Nico > > Thanks, > Liam >