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 4D02737AA7A for ; Thu, 9 Jul 2026 09:25:08 +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=1783589109; cv=none; b=Fcp1GH/f16TqwgiW3WTyI5B5JnPgegQT7bpUdNDjG+b5IArF7mbLWrjJu9eHzJuFoZWR3zz4NJzDGXn1OZbX4NP4REGcHrbk3FjHGAoNg5ztx+ZNxU+qv58qxf+ADsm4zzUFpBcJRBe10dKuH2sTYNuz3A3jSmmLyvv5IH8BMH4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783589109; c=relaxed/simple; bh=P6N6xO3jiXC17j35RozzgSiXhE/5ke2qgViVz/0PmXI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Y+qqjD4Nd/qo7fFast8h1bZiT+4JB+OplLBg7v0Mb51H0hgq/I2WYRBpUnCz4Q1OF7c0luLqTysz5KkjERWF9w7fkEtIUvGt6bfJCEqdT4eLd7nMRN/E/yGKJOOph/d16MObCCxTQelH6VzKnFtG/SOwDeIb6/p7oTFY5AYxOuY= 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; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=VrC7iemp; 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="VrC7iemp" 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 5FCC9357B; Thu, 9 Jul 2026 02:25:03 -0700 (PDT) Received: from [10.164.19.51] (unknown [10.164.19.51]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F2F8B3F66F; Thu, 9 Jul 2026 02:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783589107; bh=P6N6xO3jiXC17j35RozzgSiXhE/5ke2qgViVz/0PmXI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VrC7iempF4TXRSX1kWqoiXsHnH01XpWNbyVdeZ5LtBeGHQU/ZLWMcjNuWVgAnz5kH Y/uoNHUZVmg+A15K5lQ3TXSmUjktXyO/m8vFqyYN+Qnbdehbcd7uJ2EwtzLfeY8LnV DbOeboPfAdk0qZYZoWLIlv+gHa307jgmwoMS9vjU= Message-ID: Date: Thu, 9 Jul 2026 14:54:57 +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: [PATCH v4 02/12] mm/rmap: Add try_to_unmap_hugetlb_one To: "Garg, Shivank" , akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, chrisl@kernel.org, kasong@tencent.com, hughd@google.com, liam@infradead.org Cc: riel@surriel.com, vbabka@kernel.org, harry@kernel.org, jannh@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, qi.zheng@linux.dev, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com, baolin.wang@linux.alibaba.com, pfalcato@suse.de, ryan.roberts@arm.com, anshuman.khandual@arm.com References: <20260526063635.61721-1-dev.jain@arm.com> <20260526063635.61721-3-dev.jain@arm.com> <9a486b16-e4ee-4f1d-8686-022ef34a186f@amd.com> Content-Language: en-US From: Dev Jain In-Reply-To: <9a486b16-e4ee-4f1d-8686-022ef34a186f@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 09/07/26 2:50 pm, Garg, Shivank wrote: > > > On 7/9/2026 2:28 PM, Dev Jain wrote: >> >> >> On 09/07/26 12:46 pm, Garg, Shivank wrote: >>> >>> >>> On 5/26/2026 12:06 PM, Dev Jain wrote: >>>> Simplify try_to_unmap_one by separating out the hugetlb parts into >>>> try_to_unmap_hugetlb_one. >>> >>> [snip] >>> >>>> @@ -2393,7 +2431,8 @@ static int folio_not_mapped(struct folio *folio) >>>> void try_to_unmap(struct folio *folio, enum ttu_flags flags) >>>> { >>>> struct rmap_walk_control rwc = { >>>> - .rmap_one = try_to_unmap_one, >>>> + .rmap_one = folio_test_hugetlb(folio) ? >>>> + try_to_unmap_hugetlb_one : try_to_unmap_one, >>>> .arg = (void *)flags, >>>> .done = folio_not_mapped, >>>> .anon_lock = folio_lock_anon_vma_read, >>> >>> Now that try_to_unmap_hugetlb_one() is split out, should we wrap it in >>> #ifdef CONFIG_HUGETLB_PAGE and a stub function for !HUGETLB case? >> >> I'd rather not, if everything builds correctly? >> >> >>> >>> I'm working on similar change for try_to_migrate() and had this thought. >> >> Wait, are you doing the batching work for try_to_migrate()? I had >> that as an obvious follow up to this series so if you are already on it >> then great! >> > > Yes, > I'm seeing significant throughput boost when combining it with my batch copy offloading series [1] > Once batch copying removes the copy bottleneck, the rmap walk becomes the dominant cost for PTE-mapped > large folios. > > My experiment with move_pages() on two-socket EPYC Zen 3 to move 1GB anon memory from node 0 -> node 1: > > folio vanilla DMA (dcbm, 16 chan) > ----- -------- ------------------- > 2MB 10.7 GB/s 64.3 (6.0x) -> no change for PMD mapped > 1MB 7.0 GB/s 14.3 (2.0x) copy offlaod > 39.0 (5.6x) + rmap batching > 256KB 6.7 GB/s 13.0 (1.9x) copy offload > 32.3 (4.8x) + rmap batching Ooh very nice, numbers are awesome! > > [1] https://lore.kernel.org/linux-mm/20260630-shivank-batch-migrate-offload-v6-0-da95d7e8b8a2@amd.com > >> One other function to batch is page_vma_mkclean_one, but we do not already >> have the folio there, so have to be careful. > > > Thanks, > Shivank >