From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (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 1965830749A for ; Wed, 3 Dec 2025 18:19:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764785982; cv=none; b=WfA7YT7O5C2Qhq9z2S7Rp+ka/BF9pfCwqVrE29BJ8/vEf94H2XEZwFlO7HiNGJ6odxPWII1e7RwFF3SsqTqLvStzDQllX6vLwi+KXbYEm/s5WFBumS9wUTEag4vH9UlOGlBEQZdKQchTWXq96PU/yrtEU3xslwXNUVYKLp2oXJs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764785982; c=relaxed/simple; bh=YHEQjDaNAyN/sLTlveLQN+NwtzxBummzcQvo1oG/bS0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jdD2LAp3iibCaUvt+A9MwzPDBMl4BmPLCo+UV7ucyL9VcHQlZA9Q6uEAiL6XJi2CqtEq10wsDBVMr2pQWwL7yVsMU2bk35NFLb4JgrZ1LeK2o+lt+atNmDUC+99ejGeNbK+BNo3kaJ7BesH2drJNA52/3zA3WNOjBONfyd0yNnQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=L6M7uRQb; arc=none smtp.client-ip=209.85.222.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="L6M7uRQb" Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-8b2da83f721so11359585a.1 for ; Wed, 03 Dec 2025 10:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1764785980; x=1765390780; 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=cvxsSNOGWdrE9akcNg/jRgoHeSCakoDs4XiZtxVygNw=; b=L6M7uRQbzP/qQYabyTnLMLB/JNXBK0ld4KG3hYa5KCbtNRrbioseylNLSuZ6obwiui 44mpLCMrQZM8UIUKjRGd6i+CRwEMYfYqNB3Uu1wdgL+xsO5X3Cs+g/XzdPpuyLCo8+T5 WN62EHK3fsT0BB/8EKJsmvXsD2bbkQsnt1oqecRnzImDxu/fzWu+M45ivK/D/N7A2LuZ h+TWFQhdurdCqTMhbO7gjd0y888bGVrPY2yilk2p9mi/hcGoNb7XqXhA9kTadHodYKnh LJTvx3UxVy+Sbp62AP+EZvG9xUG1ZEh0/Sus0dWB88wfUw/f+1oWAu5Q7dGLxda0v3dc BSnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764785980; x=1765390780; 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=cvxsSNOGWdrE9akcNg/jRgoHeSCakoDs4XiZtxVygNw=; b=rROL/jr966XT1FEEF2wsEECSD0JmlYZQGPtosLE9e0fSDwcjOb4K7Dz6+hctgNwNC6 bHL95SnbvpxCIsM8pK6D3WcRsdYeqMpqFEZTv1w7ug2evlEgR3KIKLBR11rfKNZAiUq6 72uNw0ugb2exFD0T3zjkRT0ICEslckmS9uZd5cD0KAVCmBbiDcWxaeRln28oURK2TZUH Hb4JU/3w9VbIPlhR4UGu5kqtgcfLyaDV6P/Aveu2/CDvMzhMrE6bXExrSCP7cTIIZble JrLdomlqGuRrv9LFJvdTHQTO8/LgZjpGIX3MjDrfjBzxL7P1Wsuyxq522EBU/dF2uyPa M7Uw== X-Forwarded-Encrypted: i=1; AJvYcCXfmTdxO4bULK5rexaIXbwi8mV+NrfuSXTeIL0h61NMtrbDkfqBz2wrZ+dtaQ2j508+sNdw/WHnIdXSALU=@vger.kernel.org X-Gm-Message-State: AOJu0YzEziuBWf2LmfzKWWC8AluVgKphdWrXZd7j4nssOWPOl7f5Fx7i vM4QvQYy71pzDOai/bjHSMXfrQogEXVQANX1MerZqPnd8769P2sss2XD0L5BsRdZa5g= X-Gm-Gg: ASbGncuqNYeeNU8O+4EdXm/GSzkeuQJv+haNgJooY0o1bJz9k7jWRTlQZ6WW2N6RfhK oqJhJ1i7NedkbingntAuDRqDFmqwDxTheiP+e1AdcUvu3lBJH5T6vmIb6zK8+yhFOu7woiYvPJ4 ZT3V2RyF/n4daGq3RrJBDWxbHrb4fXZM7YsWE2SF5V8lbX1Fp3CAi4JKKayiqBBEyq+TmtDj0tm 0AEZkRamLswkSwfQoLVhMdSMnZQrFmUkIMbBHuKYORG66t7xqBLxQIOOt9eN0PVssdIzA5BmEUm 6CQ+adkiSbxHEYwNH6Cba6QDYSNoROgV8eMICiam2J7rKVTR4RqBCtakEncImQ94AlMgZ62gONP KwUB17amxOvA8eSJy5wjzKzWfatKrh8uiJemE84aH0StOW1F9bQVfL9FIf0TiFpsc6oUrvTThl1 g2HKuCMU2yQw== X-Google-Smtp-Source: AGHT+IExlNX5MNBC3OYudvJIv4VEFspzEKTWEJsupXZUlcjDYuuJpB+YCUht9jfc5WZuK1q3vHl8NA== X-Received: by 2002:a05:620a:c4e:b0:8b2:ed3b:e642 with SMTP id af79cd13be357-8b615f82cbcmr63003185a.34.1764785979729; Wed, 03 Dec 2025 10:19:39 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:929a:4aff:fe16:c778]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8b5299a5377sm1334780185a.14.2025.12.03.10.19.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Dec 2025 10:19:39 -0800 (PST) Date: Wed, 3 Dec 2025 13:19:34 -0500 From: Johannes Weiner To: Gregory Price 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: <20251203181934.GB478168@cmpxchg.org> 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: On Wed, Dec 03, 2025 at 12:53:12PM -0500, Gregory Price wrote: > On Wed, Dec 03, 2025 at 12:32:09PM -0500, Johannes Weiner wrote: > > 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. Fair enough. It just caught my eye that the page allocator is running all the same checks as page isolation itself. I agree that a quick up front check is useful before updating hundreds of page blocks, then failing and unrolling on the last one. Arguably that should just be part of the isolation code, though, not a random callsite. But that move is better done in a separate patch.