From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.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 A1478439F92 for ; Wed, 22 Jul 2026 16:23:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784737400; cv=none; b=ojive7UfmMr4lryVEXhc3DZjAPHEzYywyKvvamGCHnHu/OG8zhwFK1cN3p7yZ8bV9DwYoPr/f4gUI7zmzfTH8qT4f5HDlTfkNRcYu1RkLHLWT13RCEEgOfGxwV+cOPaA/9AChE3WMpGrs0AwhnHDVBjhZ73ta5eplYrRv/HDp0w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784737400; c=relaxed/simple; bh=J28+ExHglB0htlTD6vnVVHOxjd1hsx0DYe+7MQFffRo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BACxGJyGHXC6Q09ZEz8/TYIlRBbTP7ZBpNI2VSuv7gvGyYJY3SLQ5Nar3TluAsk6Itvsn9qY6JFJl6HnWpxq5QjpUK43F6gQ8Vj4IiSFrUz/C4qFnrAVFK9TkYj5zhsW/JkHz5+MPe9zUXlP988ujkIgAAmRMAPc2r4rFspHwKs= 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=vC81YO0B; arc=none smtp.client-ip=209.85.160.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="vC81YO0B" Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-51a868b6962so146541951cf.2 for ; Wed, 22 Jul 2026 09:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1784737397; x=1785342197; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=yUYDuHaewZql8DoYUinIt0gVkuOzRDMB1129ESkkAws=; b=vC81YO0B2GuUM80CP9xcggPsYFwrc7UZgGqNuQD+GGSTjHljjoj1LOTPfUE36O0sXE u1W/Oz0m70G15lNFrEh0HznXY7HOt2px1mNOOkuQ2LbTE7uG0h9P36pq2nNY5Xs9/wpa 5p35SJgx/tx20C9BlDbtHTGc0ow9g5amonIMIvL9sZ1KR4qz1mQgfVbc387CXCvB3SoE V4LkCdMvPieZ9KYuae0qsX3Rvf4FufN1DmzFmyK+rWVyHbbp/9XQbUwi4Q1X87XCNf94 mW+rJZ3dXXsCtIzQT4kl9h1jGZVK55sU5hXV3f44TAMQs0Cn2SeD3Mop53jGc66LdgvJ S55w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784737397; x=1785342197; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=yUYDuHaewZql8DoYUinIt0gVkuOzRDMB1129ESkkAws=; b=nMgSU4KSSk6H2kYg2XsOSR9kpQKudE8t9ZTX4XuNIwH/EKWJOMWFSwuJ/I8Jihp21v LMX0e4+F6+nbtpn5jt1mZPYo67gMGpCgThph0QJsz3Y+5TdgBX6iyL9ZEHY8RBpga9WI MTLAHR+bUem6hsML+VskgnsY6QvLugtpFrt0cd9BNmSVg+q4tKX+jUeGfDU3IF+9v5n2 mPvvi3RbwaOAS5e5BcgTswAtpzbIo7cMjqYqO59OWtNVgvS4NQcMMCg9+oW3Fh7pcnjD P9HajlHQQLsUCy6LTWN6v+Aa+Zl3zETdJB7NlejMHo7XyQN/paYXgbXr0bNKpiHuEfrT 3IYQ== X-Forwarded-Encrypted: i=1; AHgh+RreTK8955SYCBigzhd3sCJ0hjHjIHHYLx9Ph2XzLOMex+y7iAr+0SP29ejpQnUzPMjTkM6WNn+NHQlaPwo=@vger.kernel.org X-Gm-Message-State: AOJu0Yy5Hw3Mywg96e6VZraKiyTPrzUEPVW1T9EWNfyFthiHteEJTumD Veilwla+5f7lAhLmn7yYLa7d5nTaSVzB+vwAu3U5LG6ysdyknT8yVVNfAuzGIa6DcOA= X-Gm-Gg: AR+sD11gVEEMhXwHKZwtliH7H3AtI2zAZh8Mc8jRKGQiuHKNPZx0uUJLzILq+SsW66H uYfzesuszVMEt/QVtneit2iSwSqlIs8f3G8wCLFtbyrqwkwN+NNzhWNVuepIvhvVNuGN8UxutSO +wxtjMmmBZ2MGR+65wckx7D8wCvVT3KGOrc8DmfEcZJbbanHcou31JNo/yQENUmbSf3h0BfC9Z/ SO8FTLfWRMe2q3ik90Xp8DCgRi8URCfFZNG6j3YYawH76sjJf6Pqayf1vj4LnzYFW0viRobx9Jk YwLmSWe6eGTi9863nbIokrzV5zvbBaO2XVqyZ9vmPSi1Iqo2PXsgxJcX9cd3AvVv495yJCnVVx/ B4WrDbxnPJPVm6btpKZtjYTubPimRwV/9jig8T89iHO5fPRLX8yVQyWMW5TdYEBHiF2wiflLm9f pEo1IIAwvci/RDEBF5nDkwoD8Amvzj5TfQF2xTt7ih2q47ssLsigKmRRci0A== X-Received: by 2002:a05:622a:2c8:b0:517:9570:c1bd with SMTP id d75a77b69052e-5213cec8dd6mr228741971cf.25.1784737388008; Wed, 22 Jul 2026 09:23:08 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-173-79-60-52.washdc.fios.verizon.net. [173.79.60.52]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-527d3d3e121sm18278841cf.29.2026.07.22.09.23.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jul 2026 09:23:07 -0700 (PDT) Date: Wed, 22 Jul 2026 12:23:02 -0400 From: Gregory Price To: Johannes Weiner Cc: Andrew Morton , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Zi Yan , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Mike Rapoport , Shakeel Butt , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/4] mm: compaction: support non-movable compaction for pageblock requests Message-ID: References: <20260722150006.3848560-1-hannes@cmpxchg.org> <20260722150006.3848560-3-hannes@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: <20260722150006.3848560-3-hannes@cmpxchg.org> On Wed, Jul 22, 2026 at 10:56:45AM -0400, Johannes Weiner wrote: > While trying to fix a reclaim storm in defrag_mode, I noticed that > non-movable direct compaction is extremely inefficient. > > When searching for space to evacuate, compaction only allows blocks of > the same type as the incoming request. This is to prevent migratetype > pollution, where a small non-movable request frees space in a movable > block and provokes the allocator to fall back and pollute it. > > This protection is reasonable on one hand, but the downside is that it > makes non-movable direct compaction nearly useless: if we get the type > annotations right, by definition there aren't any movable pages inside > the non-movable blocks it is allowed to scan. > > With defrag_mode, the goal is the production of whole blocks, which > are essentially type neutral: __rmqueue_claim() will convert them > wholesale on alloc. This makes type mixing and pollution a non-issue. > > Fix the pollution gates to take the requested order into account, and > allow whole-block requests to scan blocks of other types. > > The only exception is CMA blocks. That type is sticky and these blocks > cannot be claimed to other types. Continue to be strict with them, and > allow only explicit ALLOC_CMA requests and kcompactd to evacuate them. > > Reviewed-by: Vlastimil Babka (SUSE) > Signed-off-by: Johannes Weiner The CMA interaction took a second to grok but this makes sense. Reviewed-by: Gregory Price