From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-b5-smtp.messagingengine.com (flow-b5-smtp.messagingengine.com [202.12.124.140]) (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 04EB23A89AE for ; Tue, 20 Jan 2026 11:19:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.140 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768907994; cv=none; b=CNNkprAJ89sL8x9ivzmTtRJjkSLBiq7IXeo6B0xkUo1fpY9LwcdtsjcsL3Iq2XNvdvRSF0F75KJxr+MB7D03CQtCvUGPsdD4yozU3ThMWcjOVOm05UamwRjBTa1j9FiiJo5ZqjK9apW6OeK0ebao+R3V5c8xeyIAqU1lJpIQg9s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768907994; c=relaxed/simple; bh=KDEW0BATO1zupJOQ8u7ptR9FW5ezn7se+gHDabU3JL8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uW0iridU2rhVJ+eZYy+DOYLi4zlqJeVj4c84SWeTi9wO739cSS80JCsd5sXvifQgdmmD3cNmjb42pOm+xpQrdFTH7u008SiNrau+ZOlV8SlZ0Yg9PGXXCwI0a01lGApg2AeG5RcDZEg+yohdcZ/aAMWZ+sFVdPdBAyZixvqhJJk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name; spf=pass smtp.mailfrom=shutemov.name; dkim=pass (2048-bit key) header.d=shutemov.name header.i=@shutemov.name header.b=bplZG/Ws; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=bGwiLDt+; arc=none smtp.client-ip=202.12.124.140 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shutemov.name Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=shutemov.name header.i=@shutemov.name header.b="bplZG/Ws"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="bGwiLDt+" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailflow.stl.internal (Postfix) with ESMTP id 886B7130056E; Tue, 20 Jan 2026 06:19:50 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Tue, 20 Jan 2026 06:19:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1768907990; x= 1768915190; bh=foChf5V6FBeqdFIVO3ToaRk7LOuOObFXHZ+T8o8z1Lk=; b=b plZG/WsuoUP2kVdpM+pH8UfdS0M6Z8QrpHpObysjC1brXoYXjcVYtoLw1nYhyG1V ImOlI9X18f8I6zZjJPsaLVqWpyfpU0Yy33/4WIfGCw0PYfO7pdFXNVzCBW1e5Ovx uGWb3yw38fQjUJl4rnEG49/9WhHI9hOVWT/xoHl5sVh/7ODCp9XUzNSSfk4SUDMs 6uYZIRg4Ddg1YoHoMSMDK8gISCT9ILu1sB9IlHTbj8zWB747Qe+KCjOsdBjoO8g/ 1LJ0b88Z0SD/pxm6rCRatfYsPOHB4M0yXimj4A+GZdnqikSgySAwGyEjMc+m9Q17 96bY/qkfFcTJYyeQjGcYw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1768907990; x=1768915190; bh=foChf5V6FBeqdFIVO3ToaRk7LOuOObFXHZ+ T8o8z1Lk=; b=bGwiLDt+EvHViHcK0/T8nv8olWqcxwBhEarWWlDWnbDfbtIfRrJ ZLM7MtuBhyTplhEiUsWdrYSJXay9jV7tXvgMnvIZgZRm1MxuWCmoQNxoNh1Y9RdV Oc01W9RFtwblxXaW28eIOS53Ljs2HX08Mtajnqse0W1VYdUuIOu4TjIHdRFhMeT9 qiQFiPugGw+RizF2p7hK+g2VoFXXooDOme/4xfr95KXw0dn07chIbMFQVUE8YolT clPqFJ0lEsPDyOIGJFtjXqfmcZ48VFxgiMgzqWb57cNHuYYe9X7IYsx0rqSFXdgA FjzSWCyIM1KZf13xvnUIhWbrlHsPpEIRwTA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddugedtvdejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepmfhirhihlhcu ufhhuhhtshgvmhgruhcuoehkihhrihhllhesshhhuhhtvghmohhvrdhnrghmvgeqnecugg ftrfgrthhtvghrnhephedvveefteelgefgteeitdehvdehkefgteekteejleejlefgheei uedtjefgvdelnecuffhomhgrihhnpehinhhithhirghlihiivggurdhmmhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehkihhrihhllhesshhh uhhtvghmohhvrdhnrghmvgdpnhgspghrtghpthhtohepvddvpdhmohguvgepshhmthhpoh huthdprhgtphhtthhopegurghvihgusehkvghrnhgvlhdrohhrghdprhgtphhtthhopehl ihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhope hlihhnuhigqdhmmheskhhvrggtkhdrohhrghdprhgtphhtthhopegrkhhpmheslhhinhhu gidqfhhouhhnuggrthhiohhnrdhorhhgpdhrtghpthhtoheplhhorhgvnhiiohdrshhtoh grkhgvshesohhrrggtlhgvrdgtohhmpdhrtghpthhtoheplhhirghmrdhhohiflhgvthht sehorhgrtghlvgdrtghomhdprhgtphhtthhopehvsggrsghkrgesshhushgvrdgtiidprh gtphhtthhopehrphhptheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepshhurhgvnhgs sehgohhoghhlvgdrtghomh X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 20 Jan 2026 06:19:49 -0500 (EST) Date: Tue, 20 Jan 2026 11:19:47 +0000 From: Kiryl Shutsemau To: "David Hildenbrand (Red Hat)" Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Qi Zheng Subject: Re: [PATCH v1 1/2] mm: move pte table reclaim code to memory.c Message-ID: References: <20260119220708.3438514-1-david@kernel.org> <20260119220708.3438514-2-david@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260119220708.3438514-2-david@kernel.org> On Mon, Jan 19, 2026 at 11:07:07PM +0100, David Hildenbrand (Red Hat) wrote: > The pte-table reclaim code is only called from memory.c, while zapping > pages, and it better also stays that way in the long run. If we ever > have to call it from other files, we should expose proper high-level > helpers for zapping if the existing helpers are not good enough. > > So, let's move the code over (it's not a lot) and slightly clean it up a > bit by: > - Renaming the functions. > - Dropping the "Check if it is empty PTE page" comment, which is now > self-explaining given the function name. > - Making zap_pte_table_if_empty() return whether zapping worked so the > caller can free it. > - Adding a comment in pte_table_reclaim_possible(). > - Inlining free_pte() in the last remaining user. > - In zap_empty_pte_table(), switch from pmdp_get_lcokless() to > pmd_clear(), we are holding the PMD PT lock. > > By moving the code over, compilers can also easily figure out when > zap_empty_pte_table() does not initialize the pmdval variable, avoiding > false-positive warnings about the variable possibly not being > initialized. mm/memory.c is a kitchen sink as it is. I think you miss opportunity to introduce mm/zap.c and move all zap code. It can be done for code from both mm/memory.c and mm/huge_memory.c. Line between THP and non-THP code gets more and more blurry over time. The same can be done for copy and fault code. I think it is going to be more maintainable this way. -- Kiryl Shutsemau / Kirill A. Shutemov