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 CFDD43D969E for ; Thu, 9 Jul 2026 08:59:17 +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=1783587559; cv=none; b=l97hrZ3dgUnE5BzzWUvKFTR/KpMnqFuK+Qcte6CrwhaLDXlCL9JcSOpVZa1QmgdThQ2kRMOfPXkCahx3VrX0w6fKhYR6q5V510PrhU28U0cwc7l53zjs+427kv1zggb0YFd4T06TUhVZnFmiVEcdIEjVLwwAHNKif1ZmnSThgGo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783587559; c=relaxed/simple; bh=1HPvKEYhiPcOexS+VD2WtszNK/saz1sbI5aq1xojhi4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WrDlLt4e/D3+ZGzRtj6LvIU/ts0FIhP5YfcyglujDv8WQjGkG6UZA6liDTa2iF9+3lzuaotlgj0mTaIxB9/vMBCbk0zpmqgfMJk9rvKM6sbo/Kqs6WgP7sJpnCN3CrxZhdMFbrZnnMr9wyEPZl/aVdD5deEKCLnntBB9IVqMKbc= 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=SiVeZCvz; 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="SiVeZCvz" 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 A09C8168F; Thu, 9 Jul 2026 01:59:06 -0700 (PDT) Received: from [10.164.148.40] (MacBook-Pro.blr.arm.com [10.164.148.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2B2CC3F7B4; Thu, 9 Jul 2026 01:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783587550; bh=1HPvKEYhiPcOexS+VD2WtszNK/saz1sbI5aq1xojhi4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=SiVeZCvzxhf63YTJP3qt6tHKCKIeIEO4CGc6XP5KUMWFP21OiO+Hcunkkr2pKROeR nt0RhpR+h1WZElVlprF0qaSiFfW07mX7GKEJQ4rsYY7n0tPBFJDVJgYFInFpbkfpDW nlkiek5NtyP4gE7PqT0oEEIRF9OG7YoHbkilYpN4= Message-ID: Date: Thu, 9 Jul 2026 14:28:54 +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> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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! One other function to batch is page_vma_mkclean_one, but we do not already have the folio there, so have to be careful. > I think either is fine, but wanted to check the preference. > > Thanks, > Shivank