From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) (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 7AE14334C00 for ; Mon, 1 Dec 2025 16:30:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764606621; cv=none; b=eTynymegpX8zXW0WWrsGtbzwqYVSEDj9SEU8Ask+VQcHouFvM+UveGobOE1xeUXd12gqf41ATNB+tvjZvWwynJkg7EdoSwW9MLq9G0HxK4Y3VfrK7oF2TxMUccWSf48q2RTMQLZ+iM1aXuZ11LsbqcCa3alomQmfxfLCrjWusFI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764606621; c=relaxed/simple; bh=SJ4B/SVyDT3IZ3dwSeOqB5xW1kcAvWMog0ZwDHMBcZU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iIJzxg9AEQFqCZssFANWTwpsz/+wx4jL/c10Xk/czs+ldn4S6gV+v75/zBETx4FuDwEmVLLlQ1AowuYUBjiVQPwRhfmPISn5KBxVnHAh/QzA3+zENcW+mDwn350VxEwqOTox9pyS8hkpTYyxvft0/7KFjrm+uUuZBniP+fr02bg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=WWEnRiwB; arc=none smtp.client-ip=209.85.128.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WWEnRiwB" Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-78a7af9fe4fso38634577b3.2 for ; Mon, 01 Dec 2025 08:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764606618; x=1765211418; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=O1MajTuyRJjvyDGO8DdgU3FYNJ3zCPF5BkNOmEe9i38=; b=WWEnRiwB+MumMDgSxkgKSm1T+lQDf0LRL15VJfxCZ55HpDLaK1D99s3MmQlx+jweB7 cKmx5qnv1ScXP2luWLBn7H9ajv+XKIgw+ItDrXBfVbUZ04l1Oq2iwUq6DUmYVcjXzSwF +iLfr3Q8Ui04B9AS8TUW4O9fb7Qjc/sd8JZ8WVes+eVVLx7HsP2JsY9xbpo/WAQxIj4+ MeqpddOMYCV9iA5xe6EKKTXR62WETxZwOIGGO+OOnaAJl7fouhjh0U5Kf42bGNWRo3cr CuwGAN3s+KAnh1aJ3LYW+SYg2RRDXjWJh/SAHv3rPFmSjRuNrxdqnj4K5PrasiUlCaDe KJhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764606618; x=1765211418; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=O1MajTuyRJjvyDGO8DdgU3FYNJ3zCPF5BkNOmEe9i38=; b=KTzy0UdECikATumqTmWSDpbc97jbQ0zkoh+ic3ycCYBZLFXLS7ZEFvlnr4jq+Js5dj pNln6us+ZSMfZPAkAM9sVEltpwhpy1ySxbLBKlva15Ai0atDZuvR4ccQGAO8ke4s+XWe 6GKvZ6D5DjxxEwQNN5y7QzewjEz2O+8WQ6BTyvY4tzsxXCqRaIApYyNpVesnyaivoIRx 7zgJsPuIF34Zxs0MoByOFW/Udwt8CojM1Lrw9Vk/xQeh5CeHqgqlEfNSTjgkG268qqJ/ WnMV6PSwyQWNPR1qEIk9XxyQfzxwlEi6xnlymR4k1Ico8Msa2SbbM3Yc7kzFk1frSDno ckzw== X-Forwarded-Encrypted: i=1; AJvYcCVYnx4MUxN5MtgaXiXWn7o81QMNEY8TDKu9j5oZRjWu3Aq+PyxUKjrSA3lPPMMlBqO0Sx5nDIVXpSSFpTo=@vger.kernel.org X-Gm-Message-State: AOJu0YzDnoeINGh5kNSY+QrrsQxlCEJrVJ+wSnnVsdRjQXlbmOmx+UT9 Qck7JljJGnN7F9TrIRljScypB0bMFeoqk49dulP3xBEp1JcNbp6VpBnk X-Gm-Gg: ASbGncuc7xMebQs1nmULD/NHa5H0zgsOcg6ZLK2LugQRVMGD8aWBqwb7MncUK0Hkd8H i70vT73kVoDj70Eu5hoTKU4nUhd73WUG9Fjs+ILyQclDjh/Ec750pcqEpkcc3KO5wAEu5Zgc379 uu6GA/AB1OjS9TvQlE4LIvMWq5e9XORhti2wZ5K+iqUA97jzb+SFMSxPU2OyT8debv29tOytpw+ qWKJLzWRAEmSnRSfnylkdnT3tuthB3AYxPqPrbkaRqWYVzqz6tOgVo9O27Qez/xgp83pfZVBFm1 nat663T12irgND9CodRjQH6g+/BYX9QJ2IoHIdYgXDkA7mV2uzd+kg99kJRLsUjipuDtKZ3ZtLl u8Er/DOAfSLfDuxv8/5XdO9d25+T6EPABABXuTKMVq6t+bh/0cRhMOT8nCz6RZosScn2cps749N ZZpXyj3IDBxrSrQa5aUazHPA== X-Google-Smtp-Source: AGHT+IEsE9BFE/RlSs1hU8C9RyDgvjXgVsC/va7mMiteAnwqy29gcnBHujnkqzBPbQB4Bj4DPQkfDw== X-Received: by 2002:a53:c048:0:10b0:63f:9a63:46e5 with SMTP id 956f58d0204a3-64302a4e69emr25312990d50.28.1764606617944; Mon, 01 Dec 2025 08:30:17 -0800 (PST) Received: from localhost ([2a03:2880:25ff:54::]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-6433c073a70sm5100381d50.8.2025.12.01.08.30.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Dec 2025 08:30:17 -0800 (PST) From: Joshua Hahn To: Gregory Price Cc: linux-mm@kvack.org, akpm@linux-foundation.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 Date: Mon, 1 Dec 2025 08:30:14 -0800 Message-ID: <20251201163015.1438580-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20251121191540.253624-1-gourry@gourry.net> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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. > > 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 > Signed-off-by: Gregory Price > Reviewed-by: Zi Yan > Reviewed-by: Wei Yang > Reviewed-by: Oscar Salvador > Acked-by: David Rientjes > Acked-by: David Hildenbrand Hello folks, sorry for arriving late to the party, it seems like the patch has gotten a lot of reviews already. I thought I would stop by to share some simple testing that I've done: On a machine with 62GiB memory, I tried to see if I could allocate a bunch of 2MB hugeTLB pages, then allocate 1GB hugeTLB pages on top to see if that attempt would succeed. To test this, I made a really simple setup: 1. Allocate 48GB worth of 2MB hugeTLB pages (24576) 2. Allocate 4 1G hugeTLB pages Before this patch, I get 0 1G hugeTLB pages. After this patch, I can get all 4 requested 1G hugeTLB pages! I would share the script, but it really is just as simple as echoing 24576 and 4 to .../hugepages-{2048kB, 1048576kB}/nr_hugepages, respsectively. If you want to reproduce this at home, you might have to change how many 2MB pages to allocate to see this difference, depending on the size of your machine. With this, please feel free to add: Tested-by: Joshua Hahn Have a great day, everyone! Joshua