From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB606318143 for ; Tue, 30 Dec 2025 19:54:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767124478; cv=none; b=UHH7AF5nfK2bxVstiJPMtX1bVCakTR2k52S4jTDmfPdrTuX/ad1cQ5uR2i2TvwlSXLMgGDSay/+AotXEiOxWxcWX4zwrfhVuwrRkJ0Jk6jKJixNYVWC84BV+uVEcdMIPHYeRfnN/6ZxngAIZPho9nwuvemNsM0E8F4F/KAG/0VA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767124478; c=relaxed/simple; bh=mP5UTgwdP2k6KvELLsX/RxuLJoDdzwwydVxjz1Sy+Ag=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SsVUJqCJxR9sLGytPR5TnEom3KrtS1wP2ZxW3zZoip+OvftmPNAvtwTMk3yBg06neKRCayXU4dqWr3bclnIpd9i/UhOXPXdfSHLVeDtSqacn08bcpLKsQ39ZbeaG1pVFbmc/dA7qwbLKI3sT2j7o7y2Gz1PS3CaEUTA3BZq3fMI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HO+3Px2R; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HO+3Px2R" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30AA9C4CEFB; Tue, 30 Dec 2025 19:54:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767124478; bh=mP5UTgwdP2k6KvELLsX/RxuLJoDdzwwydVxjz1Sy+Ag=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=HO+3Px2RDeFfzJo25kvQ0u9KpB7y1cI4cxEb23zkcoNQCG4pJaCN8mIv9zLQUN1vZ MaOL4V5Ck2h6GgWQp19R6oMoX4knrIdubIaAbjgzJyzcPT6sfYjU791IOk/clgJS0W LR/NKfgjGBpr8vLYTr6EefWg9b6J6Hdz156g1HwqA7VqMh7j9zb3cDbVt4YlLIeU7G LamKLrptxh6zo0fgEZf7RuyAL/DDM8sivmK1oJ+u05nP3Xizdd35zkO5LWWoMICnB5 L3kCzi+FtHQ2sDgG5twQi67qT/G9vg06jqQ2FB9xndp45foXiSl8FEv2GeD8XwesW/ DF2dV4mVojBdQ== Message-ID: <084eee6b-6c9e-454b-a563-b2babb76b099@kernel.org> Date: Tue, 30 Dec 2025 20:54:33 +0100 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 v2 3/4] mm: khugepaged: set VM_NOHUGEPAGE flag when MADV_COLD/MADV_FREE To: Vernon Yang , akpm@linux-foundation.org, lorenzo.stoakes@oracle.com Cc: ziy@nvidia.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, richard.weiyang@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vernon Yang References: <20251229055151.54887-1-yanglincheng@kylinos.cn> <20251229055151.54887-4-yanglincheng@kylinos.cn> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <20251229055151.54887-4-yanglincheng@kylinos.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/29/25 06:51, Vernon Yang wrote: > For example, create three task: hot1 -> cold -> hot2. After all three > task are created, each allocate memory 128MB. the hot1/hot2 task > continuously access 128 MB memory, while the cold task only accesses > its memory briefly andthen call madvise(MADV_COLD). However, khugepaged > still prioritizes scanning the cold task and only scans the hot2 task > after completing the scan of the cold task. > > So if the user has explicitly informed us via MADV_COLD/FREE that this > memory is cold or will be freed, it is appropriate for khugepaged to > skip it only, thereby avoiding unnecessary scan and collapse operations > to reducing CPU wastage. > > Here are the performance test results: > (Throughput bigger is better, other smaller is better) > > Testing on x86_64 machine: > > | task hot2 | without patch | with patch | delta | > |---------------------|---------------|---------------|---------| > | total accesses time | 3.14 sec | 2.93 sec | -6.69% | > | cycles per access | 4.96 | 2.21 | -55.44% | > | Throughput | 104.38 M/sec | 111.89 M/sec | +7.19% | > | dTLB-load-misses | 284814532 | 69597236 | -75.56% | > > Testing on qemu-system-x86_64 -enable-kvm: > > | task hot2 | without patch | with patch | delta | > |---------------------|---------------|---------------|---------| > | total accesses time | 3.35 sec | 2.96 sec | -11.64% | > | cycles per access | 7.29 | 2.07 | -71.60% | > | Throughput | 97.67 M/sec | 110.77 M/sec | +13.41% | > | dTLB-load-misses | 241600871 | 3216108 | -98.67% | > > Signed-off-by: Vernon Yang > --- As raised in v1, this is not the way to go. Just because something was once indicated to be cold does not meant that it will stay like that forever. Also, (1) You are turning this into an operation that will perform VMA modifications and require the mmap lock in write mode, bad. (2) You might now create many VMAs, possibly breaking user space, bad. If user space knows that memory will stay cold, it can use madvise() to indicate that these regions are not a good fit for THPs. But are they really not a good fit? What about smaller-order THPs? Nobody knows, but changing the behavior like you suggest is definetly bad. :) -- Cheers David