From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 B6D85390208 for ; Wed, 27 May 2026 07:10:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779865808; cv=none; b=XGHoOSZF1OIqocxbJ5dO9H1bybZLtsXxKvrbm/Z71J7w/Xt9aLGh34F96pUI4ypbxC8Qvw1cd+a/PGjIjPvBcw69sLIVVjPBq5k0Ugx6b4TP+JY1yvLHEQbsKHfqTuBYRIHNMCuXFuv6miJAQa7+bQmTqgJgFSxEA+v37RcMHXU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779865808; c=relaxed/simple; bh=VM1WqkF5hNobknW3RsjnFV4Za2W+i9pvKo6KCshrIPU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WWHkqhpBpkiklyfwielZzb0Y97wsYyvakiqPa5niKDQF74LJe1uw7DDJr66ss9+lDE/7OlmJVOvIMh8xDO8e5J0q0PDvISqUW6CK1PmcuqGDS9dhuqdGWtrX8Ae6/J/qaU0XikAwYWCkbgjz9lhqPaCd3mBvM+W7hDAXFfeuSyo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=epFmn6n3; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="epFmn6n3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B36F1F00A3A; Wed, 27 May 2026 07:10:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779865807; bh=KT/HSNqeN04rDLWmc+opukkZEkW2mU5kUE+yfkxNc6k=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=epFmn6n3ZXHR9c5VL03xP1O19FQvIUFoMFxe1xgkJLC5YM53dN+0fY6A5bVunFWzf Gfn0t/PzREz/t84NTlgR3qE1+sMAfnW4lSx4cVQ79YgxVpSHNX8XwtyA9KvT0cDY73 QltxynWz+qOQTYmPGm+KTmYTGbOsHJPhxRyhC4v6f21Vwg8lFEyYq39EZ4Aat5d2ej jAWoDQjwqhDG7NJtZuYzTYWPL3mMIuX/WRzN03iiwRpqaZCLOp0aVFf3K4HnFPivWp qf4pz5/oqA539Jxv9qrYdw6yrI1nSYVA7bgp/kAbgMLdPlgvh1cauWP5B8LOSwHVc/ dBA8iPGVFPxpw== Message-ID: <38681cef-4855-49c0-b317-47357190e2f5@kernel.org> Date: Wed, 27 May 2026 09:10:03 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm/page_alloc: fix defrag_mode for non-reclaimable allocations Content-Language: en-US To: Johannes Weiner Cc: Dmitry Ilvokhin , Andrew Morton , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com References: <20260520122228.201550-1-d@ilvokhin.com> <20260521165910.e7dea6a4e591d66293d2bd47@linux-foundation.org> <2aedfd17-17e6-4dfe-8ae5-c7342ead708b@kernel.org> From: "Vlastimil Babka (SUSE)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/26/26 19:51, Johannes Weiner wrote: > On Tue, May 26, 2026 at 03:13:09PM +0200, Vlastimil Babka (SUSE) wrote: > > As you may remember it was developed to help with higher order / THP > success rates under pressure. > > The impetus for actually deploying it was that we saw issues with > avalanches of large page cache folios vacuuming up the higher-order > chunks; this (ironically) also led to failures on the network side. > > It's kind of a structural problem. We have real preproduction buffers > for order-0 pages through the watermarks. But for higher orders we > only ensure there is at least one page. That easily fails under even > mild competition. > > Since we wanted to roll defrag_mode for THP in multi-tenant systems > anyway, we figured we might as well take the plunge now and battle > test the feature this way. Great! > defrag_mode fixes *that* issue, by preproducing watermark buffers in > contiguous pageblocks - making everything up to that order more > readily available. I'm still hoping to make it the default eventually, > which was the plan with the original huge page allocator series. As we > keep leaning into higher order requests more and more, and especially > grow the non-optional ones, we kind of need non-optional preproduction > guarantees for higher orders as well. > > But there are bugs like this one, and we're still figuring out some > overreclaim issues with it in production as well. So I'm glad it's > optional for the time being ;-) Right :) thanks for sharing!