From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) (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 75627406834 for ; Wed, 22 Jul 2026 16:59:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784739572; cv=none; b=CI+q9LA5QB2ZiA0hbBCQX5hsRaDTKknv/BXCLRCjjZdkRQY/G0OyEPkHJkRhgj5mDENqy5wUPCuA95ikjq/1ZVSE22uz867YoUwKdqzUHdvuZTMPEgaj2CP8jE0f10qNaTISjxWVHKRSW3sG2L0WzAMCx9PHQ0YYJxQVpAa1aYY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784739572; c=relaxed/simple; bh=A97+EK9ShjeoEivWBWUiARyuRRjXIVYgzRBzqAtSdGI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ABdbqgkinVn1hERikzYQA2MoqgIr9mVF8Kp14n8Ssec2vYrZX9cJ4D9yXY4YI2gTKvXHhYSrKZVG2icRo4syBSXLuJI2R9zS1GQBrUesx0hBkl9tN6qxQUhUNgPksX7VXJSQ99W4A7SXwawlYFfOFmA3OUpg+RDWslT+pSotJ7I= 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=sW9lI8sk; arc=none smtp.client-ip=209.85.219.48 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="sW9lI8sk" Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-90004d2f7b7so171342726d6.1 for ; Wed, 22 Jul 2026 09:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1784739567; x=1785344367; 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=qY9nXLv8vuQAHMKqYLjCyjrlLX0YlK0rzr2P3pDbLns=; b=sW9lI8skCcQxXNw4XiB2qifs9wZyy2lRzym+K1bCL4Zl5rXf6ry2rXRTlmux2AXbWd IswHAmyd4zLwuZJ8A1ayFa4SlhPgd43ifQOvIz/YZKV91GdEtRVulqqNgAN63giFXB+e OUEYggLOecTqm1qJoll56yF2hi/bzztE6EN5PQjlpKbjFoSfSJb25WSkQWt9k5hx2fVo NGi+B3Ad6bntsnkv7GCDdmEu2mKjVDzA/RyqLbYr4ogBfnaDYGHJHcahme0rkBKt1WBV WpiMqQ0zxzgjH9H8J1Zlrw8fk4pdPGMNO+l3rCMJlNR2DWs5eoqqO27qZuiaXV3El8/V JPJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784739567; x=1785344367; 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=qY9nXLv8vuQAHMKqYLjCyjrlLX0YlK0rzr2P3pDbLns=; b=JldX0snqZ4FGZoffuLLMJHuuAg4RF3kPdB5XYNtbBXCCoxQR74nF+VRG/0sEwPVly8 1yCBN9XEw6ck1oOR/rqPyip0y04JU0R1VwX3/HowCyQFBtjw2ohYZFTMT2QmlctJpqkO 9s3de3lqFOqIsJcDbYT9jQePNYqzspypO+bCIZPMjiE6/qedFvpfARp+FAKs41OL2jeJ 5552/6RUehnNcH9Jbjqb4ADSK6WNrVd3/lkxVTU9gpB4Kdkiw1y0Wp2ODJi9xCIN6unq jmNs+17jjaIJc+c+i+21+KfHVwxvK0Vt4GtfOh9/d60AfHW/nfEcMuzRRMtx6v/Dmz+w +xIQ== X-Forwarded-Encrypted: i=1; AHgh+Rq7PzMcJ9l6fKAMCvudheel/mw1q+kW2kHt4VdbbNivYKG62Ic9Fe1N+ynOh8iwV550jtshfPJbXLKhsAs=@vger.kernel.org X-Gm-Message-State: AOJu0YxSWacdacr1mluc3OnfbFttR1+tpdCwHusUaacM8khA+x0bt5up v3xyBHz8PW0V95t4TZanYDy7CkmApVRBMl7Xw0aMJ8yLVcQNzsc40Nk8oQc8hj6bY9w= X-Gm-Gg: AR+sD13fDQZdb2xdQKeuc2wLvgymTs3XXAf62LNVjgfBeB2AvO1jheoI509iuOZxS0Y 5e/+6EB9LdLIuAdGO5zGONBWjTB6G6JQPmksmVGT3W08aIQMFnWBDfSGihaZY/sVBJpCTX7vbDi hr1meA0yMt7n+4TPNL7ZLHWh32lL4Y9giPDBEu0FOwCi3uhW6xoF+r8KwrwAFku+j03A6k+sy7Z icDLxRX+5NO7zF3Y8xdvYCRueIpMTT5dEJC1i/D107pLgf4vie9Oys/wQUQIZc9B31UyKk4BPi4 8ikrJjfo3752HA4rKGaBLfiJX8+/1bSd1zXmIES3cBcfTthhkBdZvGifoPVZgYgjmXvl5OtCPap yniC+FlE4+0tqNanfgNXd9col2TNyF+y37ADjZvGIq7VyBzarLnJItE2ZzDBH70hsNW6sXffEiz EcoDIjAHrATYIoKJIMqRS6VvT/kYiF71eqK5bs4c8JiNphGSan96YquhIygloImyCU2SJF X-Received: by 2002:a05:6214:4985:b0:8f0:56e4:10b9 with SMTP id 6a1803df08f44-907783a7325mr273324596d6.35.1784739567382; Wed, 22 Jul 2026 09:59:27 -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 6a1803df08f44-907ba672806sm25545896d6.0.2026.07.22.09.59.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jul 2026 09:59:27 -0700 (PDT) Date: Wed, 22 Jul 2026 12:59:22 -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 3/4] mm: page_alloc: move capture_control to the page allocator Message-ID: References: <20260722150006.3848560-1-hannes@cmpxchg.org> <20260722150006.3848560-4-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-4-hannes@cmpxchg.org> On Wed, Jul 22, 2026 at 10:56:46AM -0400, Johannes Weiner wrote: > From: "Vlastimil Babka (SUSE)" > > The compaction capturing code assumes the allocation request order and > compaction target order are the same. That won't be true once > defrag_mode promotes sub-block allocations to pageblock-order > compaction: compaction targets the larger order, while capture should > remain at the original allocation order. > > Move the capture_control to the page allocator and give it its own > copies of what the page freeing path matches against - zone, migratetype > and the allocation order - rather than reaching into compaction's live > compact_control. __alloc_pages_direct_compact() fills in migratetype and > order, and installs and hides current->capture_control around the whole > compaction call; try_to_compact_pages() aims capc->zone at each zone > while it is being compacted. compact_zone_order() no longer deals with > capture at all. > > Pass the capture_control through try_to_compact_pages() / > compact_zone_order() in place of the bare struct page **. > > No functional change. > > Signed-off-by: Vlastimil Babka (SUSE) > Co-developed-by: Johannes Weiner > Signed-off-by: Johannes Weiner > --- > include/linux/compaction.h | 3 ++- > mm/compaction.c | 50 +++++++++++--------------------------- > mm/internal.h | 4 ++- > mm/page_alloc.c | 45 ++++++++++++++++++++++++++++------ > 4 files changed, 57 insertions(+), 45 deletions(-) > ... snip ... > + WRITE_ONCE(capc->zone, zone); > + > status = compact_zone_order(zone, order, gfp_mask, prio, > - alloc_flags, ac->highest_zoneidx, capture); > + alloc_flags, ac->highest_zoneidx, capc); > + > + WRITE_ONCE(capc->zone, NULL); > + > + /* Stop if a page has been captured */ > + if (READ_ONCE(capc->page)) > + status = COMPACT_SUCCESS; > + Might be worth a comment to explain what the WRITE/READ once is dealing with here since it's now detached from the main barrier(), but otherwise Reviewed-by: Gregory Price