From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (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 9D7FE4195A1 for ; Thu, 9 Jul 2026 17:51:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783619485; cv=none; b=N15suPs4gQTVKZCgJQM1dPlvWFzIxjYzYBSa6yvAUFzFOiNeW0AV82dOpsqtRfIlqT36vVMaaFfqrjvaZYOj4ckhhQ7+ExM9LlMusgLB+u4DzQu7fKb4bAUGFBn3xplo5s0yk5YvOXc0X+3E2F0+a6gOsqLBwHIKchilw753iUY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783619485; c=relaxed/simple; bh=sIU+oPc7gSypwSDrlUlxfkOPFNwJR5pSgelvksQC1Z0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=u0gabIRqH53ve8s7dTbTqYwUQ1Aw4dWb5BQMZkP6CYdhWSqhEG3r2WmLMuhaMLDfDwZOgXNB6A6aQuYWF8/oMtr85m9f9dhzASIzWDKXAy2pRpcJWnqUf2c5ciqRTscGB4IPhctjwxGHQpm2sVMW//sh2nWzPcgQFw+00LHLaPw= 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=VSffDPV0; arc=none smtp.client-ip=209.85.160.175 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="VSffDPV0" Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-51c1372f84dso284651cf.2 for ; Thu, 09 Jul 2026 10:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1783619481; x=1784224281; 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=zsrwC6Kq0RUJ8ahrgx8wvLWmUknec3ZbOovjEs7ytXY=; b=VSffDPV0DmOZ2Tf0d/M+aIjWmQrp89Rz+qRx7olASVxrQND6E5Ag8em9QPpQwDtlNX xsbFw/gKoL83KzQ1SSBIUV+6paU2R38G55g3IMO0hS7Muw+z4YDm27x0TZc8xVKjBzem TMAjDj9A09w5HlGPNloR+NEwVgBtzH05OdvEl75el+XSzpxMwkOfJ5QPbYi3v5YG0W1w BUBg5g6kP0vUquaQH+eJmntekS/heMjI5Ffdh3IQSMjPlX+tPP0imumW96tCLnGtKLuY I8ouYv/rMok1u1wrByFHO/mtwcOD7KRZTosogt7KcSJS5iUUYyAkp62c7HRro8OpY843 3myA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783619481; x=1784224281; 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=zsrwC6Kq0RUJ8ahrgx8wvLWmUknec3ZbOovjEs7ytXY=; b=Qc+tQkq4KKEpn1CFewJudk5jjycuToYVhwJkJPFjCQFsaGZAtiHq0MeZeUcKXVJO2R Kv2TtmPEVaAhgJSxy77wE8Rm1h0kX7U6BdMik1gDtkW1/Fd+03N3zIbKJPFDiscJ9aKV +FR3zenXIZ3hgD+/0CDmb8oKSAexYs+GIxJVdTT2AdhS/rVsHMYkohxmj0sDwgKhjXoc ZV0nl4lV3bhEKz5FR+sllhX7wgi9cbI8QbDo4J5tnh08fm+Scyc0Q+kgiQoE1bNTL/G5 0dfZabZNEh66kAI3F46YbsgSfr1dxpdqpzeXS4JUut5zJfLGJ019kXEacmEH8DQV79ed aGBA== X-Forwarded-Encrypted: i=1; AHgh+RqAhJQkyWU9CXbVKduejnBoucwEXa6H9r0Qhd4aROHvMwIl6RxUgYZx+Xp/KnDJ6/6HQFqZDK2Pt0Se3DQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwJomTWf1BjYGSSRNoaxpMdMojJ2qsmEAOK8hDSXoeLSK6sJ4fL ym+cA6uom2Dtxu99kG3rxD9gpALtQiOROh2hadBWafTqhpCc8E57VDAZehdLrxYZCe8= X-Gm-Gg: AfdE7cm/Eb+5Wx+URDdAkZXAgvXUN8qxzHr9IySVPBgxJFmicn+wUnkGlFG7fCTT7ar /pvYEl36WWYCXQhApG7/A+h5HFdJx9uuwI59C/R/iy2lVLF7+BmFYVN78xymjkZE69xLrPxcwn4 jKkSQbs71+FXDJCgHuUNhhzfUIEmvD0wmNTJqFGQw9k+EqSHwjhlkv1hqUZdJ2ZxevixSinxDmF sAebX85HLxCJ4VjcavkDUeaXVUlyNk8l0hLTg+uU6TQSNwRknC2kD6d3pSQdbCUjj/sfADURiZQ MdgKtcC9sLUNVJnNbjo6dAa1CREf2ZLG8qgLNQDAIcp3EAo+WnZiO88ulWf5qkxBQUpY0iOknwG EKKmM+LkGnzpcOOekYV6MEWxldsB71mFX3pPqQBjLWV6TIzbOziOAan+DldEI2R1qw25Ra07Xny nhgdJIyct5oPlGHzkuuQh2ag== X-Received: by 2002:a05:622a:4d05:b0:51c:7d0:7ed7 with SMTP id d75a77b69052e-51c8b31e045mr95887891cf.39.1783619481339; Thu, 09 Jul 2026 10:51:21 -0700 (PDT) Received: from localhost ([2603:7001:f100:500:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-51caacdacf7sm104021cf.11.2026.07.09.10.51.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 10:51:19 -0700 (PDT) Date: Thu, 9 Jul 2026 13:51:19 -0400 From: Johannes Weiner To: Shakeel Butt Cc: Andrew Morton , Vlastimil Babka , 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 0/4] mm: fix reclaim storms in defrag_mode Message-ID: References: <20260626182215.1107966-1-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 05:31:11PM -0700, Shakeel Butt wrote: > On Fri, Jun 26, 2026 at 02:21:16PM -0400, Johannes Weiner wrote: > > As we deployed vm.defrag_mode=1 into Meta production, some workloads > > regressed with recurring pressure spikes and swap storms (which in turn > > triggered userspace OOM rules on pressure and swap utilization levels). > > > > Tracing pinned this to non-movable > > allocation? > > > requests spinning and reclaiming ^^^ non-movable requests :) > > unproductively when kswapd/kcompactd are overwhelmed. Direct reclaim > > predominantly frees up pages in movable blocks, but those requests > > cannot use that space under defrag_mode rules; > > Do we have these rules documented somewhere? Kind of. The crux is that defrag_mode enforces ALLOC_NOFRAGMENT in the slowpath as well (whereas vanilla just does it in the fastpath). So it's documented to the extent that ALLOC_NOFRAGMENT is. > > and it is unlikely to > > free up whole blocks incidentally for __rmqueue_claim() to work. > > > > This series fixes it by making non-movable requests participate in > > pageblock production in the allocator slowpath. > > Sorry after reading above sentence I didn't get what those allocators will do > things differently after the series (I still have to go through the series). Let me add: [...] - meaning, they will invoke direct reclaim and direct compaction with pageblock_order. Does that clarify it a bit?