From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) (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 126DC38F649 for ; Wed, 1 Jul 2026 21:11:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782940272; cv=none; b=o/831YLNnDjectGaXpv32hpGALkyIXjmxymf97W3E3qx4Mq/zECYO5oF7GI1vfd2xzneF/QUc5sj5XdXFXbLLa6qyxthYD4WVMwd5ALtwUX+Y8LP9QCg/HyC+ZLn4P4evbOi3Va1qZXCtVRik4w8dYjO2cZOLmCTZ+MtGde5bEo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782940272; c=relaxed/simple; bh=7U2aLvgrMuq1wnn/4q3NXtLGMV1jj81m1nYQ7Tqfy2U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WN7H4vUEEcgMNzZ6JN1bIAkdHpVxIPzFS8L1XbKbrW7NH8YvQ58Cqxz9CDNYwr2g3onWdYg4T73hmULn/RrIHwJcY5W8zG7iDIOu2X+UqUYFBjqbiUt3dtoduHsapstrb4l4NqYBCL1RaEHV2WBps+12kPVEOamJkMJo8QEpLC8= 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=VkooSAyG; arc=none smtp.client-ip=209.85.160.173 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="VkooSAyG" Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-51bf2479349so6873531cf.2 for ; Wed, 01 Jul 2026 14:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1782940268; x=1783545068; 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=qEFL2G6LX6dWjcof52wnkswf3cpb5W1BgA0N6v9WIuU=; b=VkooSAyGN3O1cb5adpN02/Vc2hblbR6ItxbEwuW+fpmdU2s/8zrsNaRFfHetKDVaXD Iad/c9Ra/zfn+Vx5FBxoYa0H4nv0MYfGXFyMI/VQS8lVNfrLa07NxEwgAA0dswhoaiXl 8hkpNCxJGidV+qYYhxE9BVtiFpW9iV1Mql2SiFnis7M4LthFVCtPjTZ5yNGVYKgiCkFN v7FAtIxsY5zoiq2iAxlzig1J1kS+QT6nwh/RvorhNL51kOXkX64UVJV5L2gHbp1B7FUv 2kppITI5YuPLPWQk2hW6U7qnUCHB3Nn18aZembnZVZF8+EMQrJIV593S1TRgCnuf705C 3FtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782940268; x=1783545068; 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=qEFL2G6LX6dWjcof52wnkswf3cpb5W1BgA0N6v9WIuU=; b=lmWesvQAlOSNESfuEuTW6JbMZZBUw5LsBc7y3pfBeqWcikb7xe1WQTwVBMP2ZB8GXP UTLaSJXwiP6ac6wUdM2FNirFg0UH7xY+HsBSqsS+fBti6EQ7y4X3NrnUBR88nVJ84iDK YJfg4PkVqIlRwkST28er8uJ0NMt+ylCS9Q+sLCdBaS4q3MLVaSVXK4JC8EFDoURcAF1p oN5C6g/aHE219wELvf91vhcQdoHxV+cW/Kqr2Q3AD0ahW9lblTY0Qh1HODjvvMwcdA2D Yz+UK1DN8Jxbw5y4f4pJAsT5PaVMMRqn7Ucei2tZs6FaZ2ay036BOhJyGqhEILAk3zez vr2A== X-Forwarded-Encrypted: i=1; AFNElJ9Glu+rMUVqRz7Tf75xev9JoQ+DLXak7LIn4T9qz2WUhhad82okF9P/9WhGGhHVRRI78fp4XDlkYUDRAYY=@vger.kernel.org X-Gm-Message-State: AOJu0YwAMTiQA4ttU5T+TAiI94uCmLXmp2SvnUM+WoHB0ChA3SqJZuw6 WbzcQabmUh5qc6uyrRhBRLrUswwwojen+ncJZGEBceR84Kp577Mj657IN0MKCwz/I7k= X-Gm-Gg: AfdE7cnmLMSjnrXcoCn1HnogxeiwDDlCaBR+FqCW+dKXVaUyoXdVcK1zjFDYjyL8Net jva6W54dVKdsMIoOMgHag7X6j7CdWjyWP0Cz1MgcHx9Kl5L4LOrqLvEIo+X9QaXf4TXXs53XOlv GCg+hPfuVXDo3lEukU7E6iklgYCruO7TdFeVEuvyqQcmoTaQbdU1GqvAmEMH4pUA7g0EnwRDYoQ xtQc/BZ8P+HVta2G/gdxbdTmmID4y+v+tUNXMwXMjGtR0GkdKv82WduLPl4jEpJMlkpgpO52MhY RnnwLVAUOOBOvAp/NV56YoWgXJZqqVgoR/+FM+WcAmjedHzhTi1Wh2N62XZzaeWwoWMZVPxhe7/ Phl98RwEG2U9Dy33RW9rkOA+3Vgn67iLMXfA2DsmleAu8rFvxPzHIGR7NOru3M/XoMBLfxqLtN7 IQZZahcM54LvE= X-Received: by 2002:ac8:5dc8:0:b0:51b:fb4f:afdc with SMTP id d75a77b69052e-51c26a3c584mr44085361cf.11.1782940267776; Wed, 01 Jul 2026 14:11:07 -0700 (PDT) Received: from localhost ([2603:7001:f100:500:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8f4724b9ff8sm7303806d6.40.2026.07.01.14.11.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jul 2026 14:11:01 -0700 (PDT) Date: Wed, 1 Jul 2026 17:11:00 -0400 From: Johannes Weiner To: "Vlastimil Babka (SUSE)" Cc: Andrew Morton , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Zi Yan , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] mm: compaction: support non-movable compaction for pageblock requests Message-ID: References: <20260626182215.1107966-1-hannes@cmpxchg.org> <20260626182215.1107966-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: On Wed, Jul 01, 2026 at 08:14:05PM +0200, Vlastimil Babka (SUSE) wrote: > On 7/1/26 17:28, Johannes Weiner wrote: > > On Wed, Jul 01, 2026 at 04:19:29PM +0200, Vlastimil Babka (SUSE) wrote: > >> On 6/26/26 20:21, 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. > >> > > >> > Signed-off-by: Johannes Weiner > >> > >> Reviewed-by: Vlastimil Babka (SUSE) > > > > Thanks! > > > >> > diff --git a/mm/compaction.c b/mm/compaction.c > >> > index f08765ade014..7df3a85d43af 100644 > >> > --- a/mm/compaction.c > >> > +++ b/mm/compaction.c > >> > @@ -1381,12 +1381,33 @@ static bool suitable_migration_source(struct compact_control *cc, > >> > if (pageblock_skip_persistent(page)) > >> > return false; > >> > > >> > - if ((cc->mode != MIGRATE_ASYNC) || !cc->direct_compaction) > >> > + /* > >> > + * Background compaction produces blocks for the zone at > >> > + * large, with no particular allocation context. Allow all > >> > + * block types, including CMA. > >> > + */ > >> > + if (!cc->direct_compaction) > >> > return true; > >> > > >> > block_mt = get_pageblock_migratetype(page); > >> > > >> > - if (cc->migratetype == MIGRATE_MOVABLE) > >> > + /* > >> > + * CMA pages can only be taken by ALLOC_CMA requests. For anybody > >> > + * else, vacating a CMA block consumes free pages the caller > >> > + * could have used, and produces free pages it cannot. > >> > + */ > >> > + if (is_migrate_cma(block_mt) && !(cc->alloc_flags & ALLOC_CMA)) > >> > + return false; > >> > + > >> > + if (cc->mode != MIGRATE_ASYNC) > >> > + return true; > >> > >> This now stands out as uncommented. Can we come up with a rationale? :) > > > > Let's see. Originally it came from here: > > > > commit 9927af740b1b9b1e769310bd0b91425e8047b803 > > Author: Mel Gorman > > Date: Thu Jan 13 15:45:59 2011 -0800 > > > > mm: compaction: perform a faster migration scan when migrating asynchronously > > > > This limited async scanners to movable blocks. By keeping them to the > > most productive space, it keeps their latencies down. > > > > But then there was a follow up here: > > > > commit 282722b0d258ec23fc79d80165418fee83f01736 > > Author: Vlastimil Babka > > Date: Mon May 8 15:54:49 2017 -0700 > > > > mm, compaction: restrict async compaction to pageblocks of same migratetype > > Aha :) > > > This made the migratetype filtering about preventing block > > pollution. The patch quotes reduced extfrag numbers. > > > > So now we have a block pollution guard that we apply only if... the > > scanner is latency sensitive? :) Is this actually desired behavior? > > Yeah indeed I was wondering in this direction. > > > Another way of looking at it would be this: > > > > /* > > * Allocation fallbacks can spread migratable pages > > * into non-movable blocks. > > But also vice versa, non-movable pages into movable blocks? (without > defrag_mode?). Uhm but those aren't compactable anymore then, right? There is a flipside, but it isn't quite symmetrical. Movable requests are allowed to look for movables in unmovable blocks once they become sync (high-effort, low-result). Non-movable requests are finally allowed to empty movable blocks once they become sync; they *start* with the high-effort, low-result mode to avoid block contamination but are allowed to escalate when that doesn't produce results. I'll try to work that second part into the comment as well.