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 C2388F9D9 for ; Tue, 12 May 2026 05:17:13 +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=1778563037; cv=none; b=XeRz4zOHP/sjSjJAPdIm3oYkhudSTgFRh3wYym0dih0tJYM80ui+Um4e8mZFGO+H+LiSIlKQg6ZW5Zz6Tek0s/87ccnEPvvuRYUgmC0slQSNNK6zTthwnczWDpX7Y6bg0Asl+4FfkweeS8E6EwW2jxGOzodkfFuuULE003ANims= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778563037; c=relaxed/simple; bh=Y4hGigY0F9k70BpiU31xna9CXeOYZ7Z0XhPEYNRXNWY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LEFWbSQpLKZCgYq4afv6jCsaP4VUxloLY/BN4ymdiyQ44quYW/b7HOGXQ70UcG1O21zAbewMKlgBoWYbkaD9V37VFbHR2RMSHeTX6eq0kpXfKy0OoY/tXpvL0mKzFf5oAIn7sfQZpz7qpBL0h94g8tmQ1Qyx8SX15e6f7n/jQts= 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=GihDNh/U; 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="GihDNh/U" 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 4F0991596; Mon, 11 May 2026 22:17:07 -0700 (PDT) Received: from [10.164.148.42] (MacBook-Pro.blr.arm.com [10.164.148.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ACA673F85F; Mon, 11 May 2026 22:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778563032; bh=Y4hGigY0F9k70BpiU31xna9CXeOYZ7Z0XhPEYNRXNWY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=GihDNh/UxpQCpJ+FvS6Wyg4+HgnGHcPwyHpcTelQDiTKPgD+Iq+5OebZZbAOzANAd dR4rW31deuyFdastyRpBh4IStBOJUurje6HR6tSh/qiyOQ+Cs0YaRxrPVKkYzy+Yxc Pv7r7oyT9HxNy8Pq3oHiS3JbijllXMO2jHBnVEtw= Message-ID: <6b835925-99bd-4d93-b976-7fafe71a5143@arm.com> Date: Tue, 12 May 2026 10:46: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 v3 2/9] mm/rmap: refactor hugetlb pte clearing in try_to_unmap_one To: Barry Song , "David Hildenbrand (Arm)" Cc: akpm@linux-foundation.org, ljs@kernel.org, hughd@google.com, chrisl@kernel.org, kasong@tencent.com, riel@surriel.com, liam@infradead.org, vbabka@kernel.org, harry@kernel.org, jannh@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, rppt@kernel.org, surenb@google.com, mhocko@suse.com, baolin.wang@linux.alibaba.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com, pfalcato@suse.de, ryan.roberts@arm.com, anshuman.khandual@arm.com References: <20260506094504.2588857-1-dev.jain@arm.com> <20260506094504.2588857-3-dev.jain@arm.com> <5a4c3c3d-66c8-4ef6-bb6a-2ec0e32694a1@kernel.org> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12/05/26 3:50 am, Barry Song wrote: > On Mon, May 11, 2026 at 3:10 PM David Hildenbrand (Arm) > wrote: > [...] >>> + *pteval = huge_ptep_clear_flush(vma, pvmw->address, pvmw->pte); >>> + if (pte_dirty(*pteval)) >>> + folio_mark_dirty(folio); >>> + >>> + *exit_walk = false; >>> + return true; >> >> >> Can we instead introduce some enum that tells the caller how to proceed? >> >> I assume we have >> >> (a) Abort walk (ret = false + page_vma_mapped_walk_done()) >> >> (b) Walk done (ret = true + page_vma_mapped_walk_done()) >> >> (c) Continue walk (call page_vma_mapped_walk()) >> >> enum ttu_walk_result { >> TTU_WALK_CONTINUE, >> TTU_WALK_ABORT, >> TTU_WALK_DONE >> } >> > [...] >> >> In the old walk_abort case you wouldn't set ret = false? >> >> When returning the enum you could simply do something like >> >> switch (ret) { >> case TTU_WALK_ABORT: >> goto walk_abort; >> case TTU_WALK_DONE: >> goto walk_done; >> default: >> break; >> } >> > > I believe I suggested the exact same approach in v2[1], but Dev didn’t agree :-) > > [1] https://lore.kernel.org/linux-mm/CAGsJ_4zK1W71iSP14gi=8yWSg80EjgYiBXqLChB2i+X+RSTWcw@mail.gmail.com/ I did mention your suggestion in my reply to David haha :) I'll see if I can do even more refactoring with the tristate - it doesn't feel nice to do the tristate at one place and then leave all others as it is.