From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E47C398FBF for ; Wed, 3 Dec 2025 17:53:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764784402; cv=none; b=a25mwDzOTCzUe2laH8ZLIVHyK/XfzTUNoyebCTCoqccbhHpx5RBPQpWF3GQMlsIf4FPEo1GnvSFeGa6+r5cvP+zfkZAgNu4d4O/7SRf54ZgMeioJyVnrbEcmXAtlFJ+bb3LVk5bSmqgrgh49YveW87NmMC5IFli4V1xpPhSBBPw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764784402; c=relaxed/simple; bh=69foOxwTqjTIJ5Q+eAFS5+Lr5Mwxq7uRbCD4aAWJzIk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=T8Zd+71ji6dBo8UVYq75GXgRi+uFBLbMbAUaf3WSrlHDLAPXqgzDTXM/MNn+wXCQIaZB0yX+w43pMajYg+hrrX+atxV9PtO+ZWb2x7x655NNSRPM5EGipSsirqcWwPdOoi3tK1vjQHiFHo1Lf7l08VuaDvylPDNkef0CXSdb7Yk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=FRy1DhTP; arc=none smtp.client-ip=209.85.222.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="FRy1DhTP" Received: by mail-qk1-f181.google.com with SMTP id af79cd13be357-8b5c81bd953so158191285a.1 for ; Wed, 03 Dec 2025 09:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1764784394; x=1765389194; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=lVJlOc8ND/Iyf2S5FSwKg8rOfnG5RDtAsn0WPd8mpfs=; b=FRy1DhTPtFj8Yq/RWnZ3ZAweUUmtydxH4rPj7ZkUGsDXdUL6tVaJociC6gymdqEs0j SYNjwF7dyovCE9kTxyNfiWjnGhyH7YzySpMO+Jryt4DHiFo5NB4K3nFdyWBs6DozWuk/ VsLtKzNnZwyXsNPMFj7cwOy4pmHSFDYYHZsHrVpl1uLg78kvx475Ey2gK2vdh1nAXmKP nymmSXIFph7fenA14RGOIftsklHjke5eVigQYl9O0bE4zi3Hp+RM/BqpgqNDGvNREdeD cnjU0yw+Jal52CIwgRT7FFnUy+vcCWbDzl9q72df9GKilANLpxyPtLAFXZ4JSo79Lrss 2/6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764784394; x=1765389194; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lVJlOc8ND/Iyf2S5FSwKg8rOfnG5RDtAsn0WPd8mpfs=; b=UESqVxv9j6yRIc0F3FdrbwNQmlNa9y5E0AWQ5fak4gRyc+yaR1AgEMeSnCbBpLnHmh pGg0lgSkAimnA1zSG6zLsJA9zv2gOjbMCrbWPLCu61CihPRTarLKiA7hAn5GsA+V/rXW 9SdoZs4HzVsJpzsBBPLpz2M7qeies2phga5yDoA+NR0tFmDYkjysr+cBjq03ohzROZ7H toKJsEqN90ok66SB7Vjqr/pHwFBRZP0rKRic+lOk2RIjMW8lihu54KH+3lrN9Y3Aw9Dn z3e6Pq19OdmcmvOB9qf6DTbX608VcWu8AumCNbzYKVTF/1VOspg8OhsNFX2gGYPo8EhM Ir7A== X-Forwarded-Encrypted: i=1; AJvYcCXImEnj4HT5IrF+zQpYc2WQrbbfna3qh2fzrTDrQcP5yY0h+f0u4UigAfydUFKGqQD2rW4GPazExhTA4ag=@vger.kernel.org X-Gm-Message-State: AOJu0YwekUapkw7G5nKMih1fZ1bKmFbiFsW9hbhxCWENGfl0Zq8uxCX2 mmwYJXhqQ1XHyWQJLhsf3IvAEwfHUtNDw8Mpvej1DRmvamjEsSdkYHNHPwfNBFsDEGE= X-Gm-Gg: ASbGncudBL5PD+grVO80ohohOvSZvLrS4yTpyjulYjp8Om/dAPgqwW8/EUvOAPi9/Fz fnxVlPTefMJVcvHcmOX26PxX0qSw1vrV6PVyL9bbDK6whDTqHxhHa3uVAGvew8brep8MMG3aBvx v4iNrnpYI7+vEFzXHVZGPC4cA20tykt3WKOczcg8FrQjR+7Z3sPyR6SVewdSTjU17dI6hoYMPZT 11tvQ8ua/PLaDBGJ3eZ42aNeTLbw4fUJeiEaPot0ks2jsxpy4nV7C+ZFFYyAUmUrEk9xAY92GHS 2j0KjtvbmBvf10iTVfvUivWkcDoU4n4/PXui32t4j9dIcRwEWoLk0OdXSljRVS/Do1NU7Jl2zXy LO77L0MQMMzfaHkZzWWCzYFL96DYYsK1j3Td+fFUGF0JyZgp3vB2QKV8kd42habk5V3uajT37Ng qAHntwDIm+xlBweIurwLPuLT7oN5TDFwRsHSd7fWFUsjzLlrnY5+H9S9yXKz8NIwmL1/4Z7g== X-Google-Smtp-Source: AGHT+IHHD5+Jl7GtUH8NhBzm6kCviK25Go8YNEW6lOEadSIHifkHTfsNCnR07LpsAcRGWeAu1C3aGA== X-Received: by 2002:ac8:7f4a:0:b0:4ed:b6aa:ee26 with SMTP id d75a77b69052e-4f023ae1140mr209871cf.55.1764784394367; Wed, 03 Dec 2025 09:53:14 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4efd3444557sm118131171cf.30.2025.12.03.09.53.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Dec 2025 09:53:13 -0800 (PST) Date: Wed, 3 Dec 2025 12:53:12 -0500 From: Gregory Price To: Johannes Weiner Cc: linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, vbabka@suse.cz, surenb@google.com, mhocko@suse.com, jackmanb@google.com, ziy@nvidia.com, kas@kernel.org, dave.hansen@linux.intel.com, rick.p.edgecombe@intel.com, muchun.song@linux.dev, osalvador@suse.de, david@redhat.com, x86@kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, Wei Yang , David Rientjes , Joshua Hahn Subject: Re: [PATCH v4] page_alloc: allow migration of smaller hugepages during contig_alloc Message-ID: References: <20251203063004.185182-1-gourry@gourry.net> <20251203173209.GA478168@cmpxchg.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: <20251203173209.GA478168@cmpxchg.org> On Wed, Dec 03, 2025 at 12:32:09PM -0500, Johannes Weiner wrote: > On Wed, Dec 03, 2025 at 01:30:04AM -0500, Gregory Price wrote: > > - if (PageHuge(page)) > > - return false; > > + /* > > + * Only consider ranges containing hugepages if those pages are > > + * smaller than the requested contiguous region. e.g.: > > + * Move 2MB pages to free up a 1GB range. > > This one makes sense to me. > > > + * Don't move 1GB pages to free up a 2MB range. > > This one I might be missing something. We don't use cma for 2M pages, > so I don't see how we can end up in this path for 2M allocations. > I used 2MB as an example, but the other users (listed in the changelog) would run into these as well. The contiguous order size seemed different between each of the 4 users (memtrace, tx, kfence, thp debug). > The reason I'm bringing this up is because this function overall looks > kind of unnecessary. Page isolation checks all of these conditions > already, and arbitrates huge pages on hugepage_migration_supported() - > which seems to be the semantics you also desire here. > > Would it make sense to just remove pfn_range_valid_contig()? This seems like a pretty clear optimization that was added at some point to prevent incurring the cost of starting to isolate 512MB of pages and then having to go undo it because it ran into a single huge page. for_each_zone_zonelist_nodemask(zone, z, zonelist, gfp_zone(gfp_mask), nodemask) { spin_lock_irqsave(&zone->lock, flags); pfn = ALIGN(zone->zone_start_pfn, nr_pages); while (zone_spans_last_pfn(zone, pfn, nr_pages)) { if (pfn_range_valid_contig(zone, pfn, nr_pages)) { spin_unlock_irqrestore(&zone->lock, flags); ret = __alloc_contig_pages(pfn, nr_pages, gfp_mask); spin_lock_irqsave(&zone->lock, flags); } pfn += nr_pages; } spin_unlock_irqrestore(&zone->lock, flags); } and then __alloc_contig_pages ret = start_isolate_page_range(start, end, mode); This is called without pre-checking the range for unmovable pages. Seems dangerous to remove without significant data. ~Gregory