From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) (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 6DA382F5480 for ; Fri, 21 Nov 2025 19:42:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763754169; cv=none; b=j4+ihsemqrE/SXJbDkyLOHYIE65PCJ5K+TmpgIJn+k7SU+qTxyANwBiJIKhEeRSrSfHKgbkSbCNr+Y/GT2JXf8OrmLt05nTX/8KhhY0+lJEqe9c3NBxSzsMAIpaNP19PstpeEAmgHwGa396aB52vwQtnZVxrKwRk8WcRzUXEU64= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763754169; c=relaxed/simple; bh=1XxBKYBgmCsyod5rpVXyNigi5kpBQEP/81JnDwlhmHU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ya7VRuu/49bLLAG1wO+c5XFMl2/8cNbFUnGcOl+afvy4H05BXMajB1K/NjkYxRyGBWOa5iAlhpA6xjaSY4QQfxMQT6R7WITIp4/aK01QnPKLFP3vTw98OevtlJaqLXJ7ATZUP9HtCecoteYzb//NBQfhCvodsE0bnznavnB6zh4= 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=tADEBWCi; arc=none smtp.client-ip=209.85.160.177 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="tADEBWCi" Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-4ee19b1fe5dso31608491cf.0 for ; Fri, 21 Nov 2025 11:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1763754166; x=1764358966; 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=tHczAXBW36ndePVrSwtAmC2KCcD+LQ9uYV0CS0eNwa8=; b=tADEBWCiY0TgTsCZF0jEAT/KH4cZAcWtF5N4V8goyoUKthVW9oxUAFBxjUp/mbmgVh 4w3peJKNh3uZ4gnrDALOQJbKP5zIs9LdgSMdatq3P6aSyI5pTCq5nJu0+ZwZSoeU7YME ulqEK8Qk3qlnDOMYgEul2r2RKzS17zqHDUjgcX5O3iR9pgGNWPikZRR4AaTMh7frdc2E 3Z6/ii40WnjVEFN98CyFIzByGt+xRvcRkcLfHq4ZX2hC12+83taxgPYTV9Acnwms3pEL x4qFRH1Quotq1VGFUJGIaFigkKvGoN+Z2yxMEizZITynFiEgDf4qfXFnTL/i5ZWIgk/O x15w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763754166; x=1764358966; 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=tHczAXBW36ndePVrSwtAmC2KCcD+LQ9uYV0CS0eNwa8=; b=Ne0JU4aKGrikjFtn8O9a57bAajBMRN/7VdFW4dUKvmmLbYa21E2NPN50C3UUjOI5iQ 8iaVugSDG3IDm5wLBhwcTV4tbhzHw8TqB6vsh1ZtNAWDeG0UD+fHc1R1FjLow0/B9MgC Pa3cKkGpJfjArJSKWl2b1PHbEJyIwJ23tcOTF9acwZpIqTbhFoZ8WhaYcgC8BS+lHSsa nZYdnXfFQSVTfQeN/5OtDu1ZmCOTWAV0jdNb4IU5Ze5ozQ+slqL5QEUIfplZt1Y1f3zh WP+sQQNn7X1C4FWmVbMjIPzh7hox/9r3tqY7JsRsGdHrAFNl/xqJnjqB2ZUAerhI143K qsfA== X-Forwarded-Encrypted: i=1; AJvYcCVsckvdJfYj47qJemPn0Y0WcVJqihDv3D1Z6Mq/HwEqY7A+jiTRVFGw3NNUX99m59p1WZHchHLCp3mjOpA=@vger.kernel.org X-Gm-Message-State: AOJu0YxkcwHqRLUhtMWyhZBOZHs5YV6IZQTgDoYpfVi9ft6u8/B3/lUj tj6M7geRVpRORgfUy+uZB7jnxZ0FbA/miiSuogjZM26/Odl/CgWFDbAl6z/b4sBPj9E= X-Gm-Gg: ASbGncv+H1xzEJJKdnUcx9gqZvpJklQEeE0gF8ipDZvHDVHcjlmbAvshhfChfXyWmX2 KNq90BzZcGo4c/wx+Qp/oNJ8igMX5HHpecLF2Xp1M7IUc+EIWgo+9N16RbQrUv6RbqOmqTdIZq2 Xp2m9ekkz2zDeg+xJiXI5oLXJv1dJT4DII4jSag0U/JWNT9t2NCMgLb86w1ixbyyX4ctbo5sStS pi9vjcSdcShuqbZRoN//VAVXs8MvNXC4u9AKXnJfgxFBoVxpxuydEQywNzXIWO8tzj1z9RwX4m1 FGgr7Ez7Aj3SLUyVjOGkFAsxJJ6IYllDaB9wDvYOeTjeXaYPjHOs+wNUGx0HUl910sccB+KsZ81 lZI44w556Vk8SUpD+2IuhoRZMPypKp4v4pNTN5VE8FWdP5IARLPMJS8aJFvS9e9bQAt//1wjCCj jZosbi+jV1dwhzoUE/RFxGNYl17K9K68F7N2/M6EZ5/f1rfa9uZJ2abB+HrGxGiQzZy9vEhQ== X-Google-Smtp-Source: AGHT+IFqNQg9VGR+ih9PF1dPXeGmqhotPlRcYalUXtahRUMLDoaN5FmikK8sTfrdHPaIneNGj/5byw== X-Received: by 2002:a05:622a:1b88:b0:4eb:a24d:8c17 with SMTP id d75a77b69052e-4ee58857093mr54018581cf.31.1763754166168; Fri, 21 Nov 2025 11:42:46 -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-4ee48e46ed0sm40315241cf.20.2025.11.21.11.42.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Nov 2025 11:42:45 -0800 (PST) Date: Fri, 21 Nov 2025 14:42:35 -0500 From: Gregory Price To: Andrew Morton Cc: linux-mm@kvack.org, kernel-team@meta.com, vbabka@suse.cz, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, linux-kernel@vger.kernel.org, David Hildenbrand , Wei Yang , Oscar Salvador , David Rientjes Subject: Re: [PATCH v3] page_alloc: allow migration of smaller hugepages during contig_alloc Message-ID: References: <20251121191540.253624-1-gourry@gourry.net> <20251121113138.9955cb18d9b6c7ce812d5c0a@linux-foundation.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: <20251121113138.9955cb18d9b6c7ce812d5c0a@linux-foundation.org> On Fri, Nov 21, 2025 at 11:31:38AM -0800, Andrew Morton wrote: > On Fri, 21 Nov 2025 14:15:40 -0500 Gregory Price wrote: > > > We presently skip regions with hugepages entirely when trying to do > > contiguous page allocation. Instead, if hugepage migration is enabled, > > consider regions with hugepages smaller than the target contiguous > > allocation request as valid targets for allocation. > > Why? What benefit does this have to our users? > > Some runtime testing results might be helpful? If multiple types of hugepages are in use, alloc_contig is less reliable. In particular when 2MB and 1GB HugeTLB pages are present on the same system. The same logic is actually present in isolate_migrate_pages_block() as pointed out by David which is called in the stack from alloc_contig - but it's unreachable because this filters those regions. I allude to this in the second paragraph, but it is worth spelling out explicitly. Will update. > > > isolate_migrate_pages_block() already expects requests with hugepages > > to originate from alloc_contig, and hugetlb code also does a migratable > > check when isolating in folio_isolate_hugetlb(). > > > > Suggested-by: David Hildenbrand > > A Link: here might be illuminating. Ah, fair point Link: https://lore.kernel.org/linux-mm/6fe3562d-49b2-4975-aa86-e139c535ad00@redhat.com/ """ However, it also means that we won't try moving 2MB folios to free up a 1GB folio. That could be supported by allowing for moving hugetlb folios when their size is small enough to be served by the buddy, and the size we are allocating is larger than the one of these folios. """ > > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -6849,8 +6849,19 @@ static bool pfn_range_valid_contig(struct zone *z, unsigned long start_pfn, > > if (PageReserved(page)) > > return false; > > > > - if (PageHuge(page)) > > - return false; > > + if (PageHuge(page)) { > > + unsigned int order; > > + > > + if (!IS_ENABLED(CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION)) > > + return false; > > + > > + /* Don't consider moving same size/larger pages */ > > Comment says "what" (which was fairly obvious). Please reveal "why". > ack. > > + page = compound_head(page); > > + order = compound_order(page); > > + if ((order >= MAX_FOLIO_ORDER) || > > + (nr_pages <= (1 << order))) > > + return false; > > + } > > } > > return true; > > } >