From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (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 50B2E33120E for ; Wed, 1 Jul 2026 15:28:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782919707; cv=none; b=OdcHLKwvC+wF2bAVW+9fl+GBXKE9N1G2F6y/jTNeny08qPE3QyO7eqgDdZXWeb23XwWVtBuRAeeRsRJHBUqZjcogc3IAFvISafN39rbUj6MkeQR2PeYRVeJZjJvIXNBVw3DtRTxAYNRaSnHVuLQGw4+8NuAyfITj0gf8Pd44Vp8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782919707; c=relaxed/simple; bh=SKDd83TnahVewh1xMSDChlOke8TqWKRxGjtjJcToAu4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PaBMAjp9ia6jRUwuaxACVfnrEL8gGhuCC5GY+P807mTiADF6OLgzPfRAK+QUBF4+e8KWFULok7NrKR4Qk1b5/sWjXvcinFWto0I5nLMYYM907i5V8nW1EFL5S5VAoggyQyjtc1jrhYqIXlZeDNj19+kRwaqnbQNweHxaZWByaCg= 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=NlbLO4gD; arc=none smtp.client-ip=209.85.222.172 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="NlbLO4gD" Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-92e5cb052edso70525385a.2 for ; Wed, 01 Jul 2026 08:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1782919703; x=1783524503; 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=qhbSR1sJa9JZNfq4AjFtt9zAbsMr2JS2dPAyTfvfRWA=; b=NlbLO4gDMuDhc9N+mEF19ctsNG/Ywk9MSGakTY/kGt9W+zyJJ0itxpAv23XeDP/CIw gLEaLYUopLgjXdacb/YqHqW2SuaIIc1jmfDZvVt10j2RVTld3dne8jrDCadj1+l6/pwb bqr/XJ6zkIpxgDnHYqer3Xd5PoUGGXJnpY+nZ5+MJSZ8+UKLryrPGoHXXV60lJd1MubK 8RXuGezE1No2kBmlWhepCsvC4Dizv+8mLLGcNwu65gJ04Y+Qse6Yq6ms6UiUon2Ultc6 BhXQvPry1kNvCqfXGyrk7eBkbhME46MJ7SLC7IDr5CqZ4if4sScPM/yOsSOGg78KGxZd nXEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782919703; x=1783524503; 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=qhbSR1sJa9JZNfq4AjFtt9zAbsMr2JS2dPAyTfvfRWA=; b=HtZgNo2SrVZLakao31pCwRamZqTymUEsvHPfGg7Q/RCTdj0O3KhrOYrvzVfRV2YyO3 HDY24UTplYpxd4K2CNFOMiuSTtrkDicpx/lhSbk7V2vrFT7BBdrkAjzzbRedMzi46Alx zZ4eFNL8XbLZYhYtqDgvHPQHo66mLJea/kKy6A0yqLy41rbJ7YhPMuGTq7lpSlicAAjb hLb1jiCTV+yf4JAg+xiSMbbpKNY7wqsAp3bae201o500fOtahhAVtYRxFmS1xjUS1dQX 4OORVa/2e6nc3dWwke2wKh0Lu7MIHRNzlCTsJTqLzImiSNaHT5DOh+TnKKu0mR851iVV 0T2Q== X-Forwarded-Encrypted: i=1; AFNElJ8d/igtcPv9FaiUSJfmdV1sD99KamPpIf9qungzAfUz/bNbdtgGhWiWKBaPVlrpATyYyrrzef8v+vCy73Q=@vger.kernel.org X-Gm-Message-State: AOJu0YxYHrR0JQ70PXZWHo7/QA9G9zHLN6GjGoebOCRNV/IaOpPoVgQ9 AE7VW+WDDlYxaWh7n6xQYKIZ0Ls9MPjCiPrxBmp8VV2jP8MSn+1fLJa+qrj2M8oIF04= X-Gm-Gg: AfdE7cn+G0amqKBH9V7HPkcoxMEeLz49o2nDKtb/1vONgFdV3N6cZjp8vKUhWVxI9ti qeBVqMg5DuaVKzNhXkV/XO+RdSKcje4iozrD2/T8rh6w+Ff9pz9OltxAcSYsobC1Vm5dviUU/7R 0lMrCXgLaCy8DkfHOrUSvWNFIqzy5smmoARX2U8QEc0kDcvlSx/tG1nvSpRfBaAdCcSXK1KP9lZ LtRIdWkrvHATHakhSf+J0NFd/0htXyedO2J1RXT2H2lcvCJfWP0p5C+iALfl2ZHVJ0v7aHGj9e+ opY88p9k4ETzkfLOIGGTv/MsW1IHsM6X4/wMXBscvAIg4EnSMhmPEiGUMEpHw+1MJpiy4/pr/y0 45NKSxRkV9X2I7hU/sAX1b+5zxCZHKgA8fWfGAAvBAsPn6pXIXO2LpRsN7TkaJDFm4WlxEaAztD nuU/oZRXGFRuY= X-Received: by 2002:a05:620a:444d:b0:92e:72a4:f279 with SMTP id af79cd13be357-92e7b37424fmr203341185a.46.1782919703137; Wed, 01 Jul 2026 08:28:23 -0700 (PDT) Received: from localhost ([2603:7001:f100:500:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id af79cd13be357-92e622e7fe3sm590479685a.27.2026.07.01.08.28.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jul 2026 08:28:22 -0700 (PDT) Date: Wed, 1 Jul 2026 11:28:18 -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 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 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? Another way of looking at it would be this: /* * Allocation fallbacks can spread migratable pages * into non-movable blocks. This is high-effort, * low-result work. Restrict it to sync scans. */