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 E77822066D7 for ; Fri, 10 Jan 2025 06:11:44 +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=1736489507; cv=none; b=sTRrk+FBQAolAIkjqncCvWtaJ0zo5ZmCSHSLNPmJoYGPRvXvedggGszlEnnh8CCDOJ4NT3QQr3Z2YM3H7vfGq7fJ+rc3TdynkF24nkd0IUWslxS/RXduemS615ipAhGR4op4tnJH1fRiUfXJFi4MDhhdJlnIDMTFfhXdJlgCgyk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736489507; c=relaxed/simple; bh=eZD4yv6mOd/K2KnUEtaHiFDV79GIO2QzxQWy/ab/evc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=AeD/jDS0LvrP/P7yTdu5/rOBrFkJyWjjbYe7kKP0kQ3ovQZdSrb0z+6biV0vhw8RBJJRouiygcpOMCugJG3IKjxAoAWki2lOqAkI0Dy2I+jjZ8ve/9R1F7acaaSGT4FWjOJYNJYlQ4vG3ooicjApZfAqkBEwwIi5FC9TCvQx9H4= 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; 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 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 0EC811477; Thu, 9 Jan 2025 22:12:12 -0800 (PST) Received: from [10.162.42.21] (K4MQJ0H1H2.blr.arm.com [10.162.42.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B85963F673; Thu, 9 Jan 2025 22:11:31 -0800 (PST) Message-ID: <3a1af9a6-451d-46ec-804f-cdb5d3d21f41@arm.com> Date: Fri, 10 Jan 2025 11:41:28 +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: [RFC 03/11] khugepaged: Don't allocate khugepaged mm_slot early To: Nico Pache , linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: 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, sunnanyong@huawei.com, usamaarif642@gmail.com, audra@redhat.com, akpm@linux-foundation.org References: <20250108233128.14484-1-npache@redhat.com> <20250108233128.14484-4-npache@redhat.com> Content-Language: en-US From: Dev Jain In-Reply-To: <20250108233128.14484-4-npache@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 09/01/25 5:01 am, Nico Pache wrote: > We should only "enter"/allocate the khugepaged mm_slot if we succeed at > allocating the PMD sized folio. Move the khugepaged_enter_vma call until > after we know the vma_alloc_folio was successful. Why? We have the appropriate checks from thp_vma_allowable_orders() and friends, so the VMA should be registered with khugepaged irrespective of whether during fault time we are able to allocate a PMD-THP or not. If we fail at fault time, it is the job of khugepaged to try to collapse it later. > > Signed-off-by: Nico Pache > --- > mm/huge_memory.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index e53d83b3e5cf..635c65e7ef63 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -1323,7 +1323,6 @@ vm_fault_t do_huge_pmd_anonymous_page(struct vm_fault *vmf) > ret = vmf_anon_prepare(vmf); > if (ret) > return ret; > - khugepaged_enter_vma(vma, vma->vm_flags); > > if (!(vmf->flags & FAULT_FLAG_WRITE) && > !mm_forbids_zeropage(vma->vm_mm) && > @@ -1365,7 +1364,7 @@ vm_fault_t do_huge_pmd_anonymous_page(struct vm_fault *vmf) > } > return ret; > } > - > + khugepaged_enter_vma(vma, vma->vm_flags); > return __do_huge_pmd_anonymous_page(vmf); > } > In any case, you are not achieving what you described in the patch description: you have moved khugepaged_enter_vma() after the read fault logic, what you want to do is to move it after vma_alloc_anon_folio_pmd() in __do_huge_pmd_anonymous_page().