From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6468C3601E for ; Thu, 10 Apr 2025 20:17:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BCA6F280133; Thu, 10 Apr 2025 16:17:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B79A728012D; Thu, 10 Apr 2025 16:17:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A410E280133; Thu, 10 Apr 2025 16:17:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8881A28012D for ; Thu, 10 Apr 2025 16:17:25 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9700112145A for ; Thu, 10 Apr 2025 20:17:26 +0000 (UTC) X-FDA: 83319244092.02.24275B7 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) by imf20.hostedemail.com (Postfix) with ESMTP id 860541C0008 for ; Thu, 10 Apr 2025 20:17:24 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b="GQWzLf/s"; spf=pass (imf20.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.171 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744316244; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GYE2DqZFp3RMAU6AvSsXNZuFJ7WeXusYrsxIjd2l0Bg=; b=fDS9lPLAxblpAgvRT6Cw9r97osk/GnOaqj0NgoJN0Okhs+GpeOQy6/W/IfdGc3ROrBdOth QDhCnbhoGEVfpP51B0R6gsEDaPLUUxRxnopgZAMa0X92JxDx7koPGnvoVp2z/RLaCsSl59 dUnx9slWItH8P16sgs0j/A3AYuj/sC0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b="GQWzLf/s"; spf=pass (imf20.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.171 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744316244; a=rsa-sha256; cv=none; b=rpnKbiQC1O2hkdhApUNVNwbPAJ1vM4HYdIE28hrZ0KYrAHcddSgQQZoew8fFXCBXUz7Ddb BxrkgAjurKwMegXf2TUJINL7YC7F5pCKWFv4//sj4rZ0823iYS3PPUDCB0apG+S9/nKO11 93pF+OgNxiIaCfvAdYF1E0x8a5XRBck= Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-7c08fc20194so243390985a.2 for ; Thu, 10 Apr 2025 13:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1744316243; x=1744921043; darn=kvack.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=GYE2DqZFp3RMAU6AvSsXNZuFJ7WeXusYrsxIjd2l0Bg=; b=GQWzLf/sW5YCoXBLVitlCjKQNt9mCYpI4/wDLRuWSnPUmOLfeKqIY7Uz6JfuylT6d5 jXBswEf+ndi92eGlw5G9y7gwicnvNgf0M+SbAafpaMtaJow473ijyCphb6MkHAUHntoG 2+fdpFPOSG75JW72p1+q1Sk0pSEC+0hVqfUQIGhkhRhax3tyfNKtbx2b1sjd/zvDhdB7 3Uix+lxG6OOttjiLP2kNg09dookgziJF8Uksnpgauny5bJ+HRziAjT9vWNpIW4JVZepq pS0Hh4uGbe3dHVUa9aNh0ykrmKEq2KL++9AUUfi0mX/z/cgZR+0+0UdKkOTr48gRDt0x gJkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744316243; x=1744921043; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GYE2DqZFp3RMAU6AvSsXNZuFJ7WeXusYrsxIjd2l0Bg=; b=sHtp2foJtKIOTZPfbD4HNqI7tXSqvrk37nI0zVCTrXpgDEuMZy/Of0DXZJretjNZKb 4UdfsW5kjueFRTecIX485GSfo+KSAYRVddpelkTwzLG/KoPykLCdtcJr+BrXeSulvjtC lm/4DeMObqlvhaWCLbl6qjeiuKl5/JmJEC18GvLPJIjK+c2wdBrcxPY6I4Yfms83Tmy4 BYsFcIT9wGsDnNnnI2J6RC3OKDa1qOhF2nmFW33wsglHhwV+wyEdCy4j6cxOZH+Dnm7W 71Qf6ewmypSPjlzx7Z8REhK4y+20PFwxWY8fOy6JG4sAvpIAN7ncOBh28Z4NnPXesJqe FoLw== X-Forwarded-Encrypted: i=1; AJvYcCW+SLq07j5UcJ2792cWNj2tnrn43f3J8qb0eBHZ49GUFY2zvxhMQH5//Et3ZVSbneItH+m/2BjrnA==@kvack.org X-Gm-Message-State: AOJu0Yyf+sILhl+4KNBbynOtMJQILzOWAfnGXbNZ5MIdVljvnJ+YLtzx vdNfJhx58dgkCahVQBIAH/GpILkss2d1M+vsVH50BcSPEaiKvhDnZH6FPtwaUxY= X-Gm-Gg: ASbGncs7UyaO6+ZCivlsi0RrdlgUbN0ry1iScXt6SZwY8uhOjIiVgKdZCqMABBXy6RV pP+BfxXIf5utsVSiw3T6GJ4P/bGWgGzc9CQxOefcJKYycShAMAHqj01WugtUAPo6MOy1CLi7RDA ezBSCAm0iXIYoEdRBeWuTHkYlwWh/87IRyU6KoaQQ2LpS3KGR393KPKs+eZFvMy2z4WJ+tLvgDD piLsMTN8x1Is7/BYlGX7M8lTn4FJiJoz3FpDfOSRp6n4MG4Upb1M4JSTVKYTxKiqswafU2atpwf fL7U7O/zSm2WD5AffWieG/wpZTjrbSzHTF7DY/0= X-Google-Smtp-Source: AGHT+IHToBiY9Y0UPycGOGqHIngZX336hB/whYyZb8k7vTgrwjmw7X4OIwWfyQCkonQXDC+ZuqSYXg== X-Received: by 2002:a05:620a:bc9:b0:7c5:5339:48cf with SMTP id af79cd13be357-7c7af0e3324mr53165385a.30.1744316243535; Thu, 10 Apr 2025 13:17:23 -0700 (PDT) Received: from localhost ([2603:7000:c01:2716:365a:60ff:fe62:ff29]) by smtp.gmail.com with UTF8SMTPSA id af79cd13be357-7c7a8942f26sm145978085a.4.2025.04.10.13.17.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Apr 2025 13:17:22 -0700 (PDT) Date: Thu, 10 Apr 2025 16:17:18 -0400 From: Johannes Weiner To: Vlastimil Babka Cc: Andrew Morton , Mel Gorman , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/5] mm: compaction: push watermark into compaction_suitable() callers Message-ID: <20250410201718.GA366747@cmpxchg.org> References: <20250313210647.1314586-1-hannes@cmpxchg.org> <20250313210647.1314586-2-hannes@cmpxchg.org> <2025de6c-a25b-42f2-8ff2-da2bad0e0aa0@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2025de6c-a25b-42f2-8ff2-da2bad0e0aa0@suse.cz> X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 860541C0008 X-Stat-Signature: noxfza3tfffo8roaqy8eg6ubskb6s8sp X-HE-Tag: 1744316244-201016 X-HE-Meta: U2FsdGVkX18naOlZeprCxweK9CxKp2kDo1KBYHeyk2pUbDGNfZYo91hZ6gf8y2LeuxekZSTTYIjlABqTGlkydccv88sQM+3Vw30YmyWMQwmBFAK7FeFlEiAADRHJjJfr9tCObduciOa61iAteesgqOSUf2EQYANJmPa/zJeNA8yDLq/2lG8F5wkHOA7AvzrBbU2drKU9Mlqk05Uikr2V4Twj4mrqhtRbQUxiJ3tCM2O0ShBREv2BjDAG2UnZMW2pSxA1CbeBafo8zOlKjhFvA6RlL5Z9hddY0OKBSl5U/W4ECViqI4Wy6gvIZAIwOSulqiCC5w0Rx8oxpts9PQ47wHfSgmPa6hKjEn/0HEcJuAGDGfvsAmro322nhh5p1zOxlA0ioEow7iNV/9mRlp7zuezekNSbW/yGHYBemOhyPzJuhGb3YkgudbphfPVSimUR2dVIdEnqRmP3X0EkeEEY/fhszPfXR52hgNo68+ZwZWSTMlR4fV8MVsKlrWK396yVcCo7V5GbhUT49DUM/JPLEVMYRYMAsIavHMn3QtEyX+AX8paxqaONVJlQ3UPE2w8pQVy0gjnqa2zQ6L2lDMK/VSqcoPDBGme/kN6IYiioJUZMZVE4xThvS43UNe7bQnNPS7HVLv/fIkqPTV7m/bHfbVRu3sWxGue5T59uqj+QzksuA0j4qD27YPAVld4cKSR5ySSOHK2WFUekcxAFZSuGdSx/jme47g0g1X6MrhfxtMMmlfkJ0CSoqz2ZM05g1rTyP+uJQevTy26v13SRb7IKu/ZNmahR47UGfyUUPmzKM9Xp5CnqcgOt3rqYLFWUsaVLhu/EmxVC5aN4JoTtPnfFF6ldJa/Qzenpda5HL2j8zQ/ngOT1zODFxKMWo8VsfSHIdQoK0Z5xS8a3iZb2XaPMivYiwco6eAKPEWijgCaMfIpmUJcJgAT3ATVfQBltrGcneErRgEb0xDCpL3vGZCP HQZPHKpm qrM/Qin3fNNFuDXeN4Bnm1XX4rRT1/+DkCENa8INoPKv2+A/pP/QD4vVo7HMW4PfV75NxO758KmP4Gm3obv/RWpFc4DjOp8OClPQuhoxeti9rL8swpfz1lYithqjzKJ1e/+JjAfpQTOShm7Qd3K6oKzpEHbTiCvABBmO3PtR42GzBXk6MgBmiKmyx5hMG5fhOdBP28l+MaNR9zIBBCoc5l0HYqY/d+SXhnaLPhAen8LGgrizJ7fImvlltOHrXeRwt9m2KEy1yePBIbCUJZJG+XlhIRWd4w2WvuD+m93/0KptSXzA5Lq/2KN5NK9oPINBVk/EpeelVJjRu5loVd/JKMecoMgy5eII1IAL9d9VDFkSstrFqcvTssLzv4X7T2ovbLuBx93ShAydsI2XrChdrPsVhXhnB27rtgmm/RdSLbhjH4+u50J+B0ROo/bO13CN9lsw1xCyR6DQzO5GD/6yQjB3xZhfu6dGYy5ZMEHJ/go8KRxmkN4BGBtgmXI3cAnI9LtOcWWNfWvzQNiC2shvYUKCz1A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001951, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Apr 10, 2025 at 05:19:06PM +0200, Vlastimil Babka wrote: > On 3/13/25 22:05, Johannes Weiner wrote: > > compaction_suitable() hardcodes the min watermark, with a boost to the > > low watermark for costly orders. However, compaction_ready() requires > > order-0 at the high watermark. It currently checks the marks twice. > > > > Make the watermark a parameter to compaction_suitable() and have the > > callers pass in what they require: > > > > - compaction_zonelist_suitable() is used by the direct reclaim path, > > so use the min watermark. > > > > - compact_suit_allocation_order() has a watermark in context derived > > from cc->alloc_flags. > > > > The only quirk is that kcompactd doesn't initialize cc->alloc_flags > > explicitly. There is a direct check in kcompactd_do_work() that > > passes ALLOC_WMARK_MIN, but there is another check downstack in > > compact_zone() that ends up passing the unset alloc_flags. Since > > they default to 0, and that coincides with ALLOC_WMARK_MIN, it is > > correct. But it's subtle. Set cc->alloc_flags explicitly. > > > > - should_continue_reclaim() is direct reclaim, use the min watermark. > > > > - Finally, consolidate the two checks in compaction_ready() to a > > single compaction_suitable() call passing the high watermark. > > > > There is a tiny change in behavior: before, compaction_suitable() > > would check order-0 against min or low, depending on costly > > order. Then there'd be another high watermark check. > > > > Now, the high watermark is passed to compaction_suitable(), and the > > costly order-boost (low - min) is added on top. This means > > compaction_ready() sets a marginally higher target for free pages. > > > > In a kernelbuild + THP pressure test, though, this didn't show any > > measurable negative effects on memory pressure or reclaim rates. As > > the comment above the check says, reclaim is usually stopped short > > on should_continue_reclaim(), and this just defines the worst-case > > reclaim cutoff in case compaction is not making any headway. > > > > Signed-off-by: Johannes Weiner > > > > > @@ -2513,13 +2516,13 @@ compaction_suit_allocation_order(struct zone *zone, unsigned int order, > > */ > > if (order > PAGE_ALLOC_COSTLY_ORDER && async && > > !(alloc_flags & ALLOC_CMA)) { > > - watermark = low_wmark_pages(zone) + compact_gap(order); > > - if (!__zone_watermark_ok(zone, 0, watermark, highest_zoneidx, > > - 0, zone_page_state(zone, NR_FREE_PAGES))) > > + if (!__zone_watermark_ok(zone, 0, watermark + compact_gap(order), > > + highest_zoneidx, 0, > > + zone_page_state(zone, NR_FREE_PAGES))) > > return COMPACT_SKIPPED; > > The watermark here is no longer recalculated as low_wmark_pages() but the > value from above based on alloc_flags is reused. > It's probably ok, maybe it's even more correct, just wasn't mentioned in the > changelog as another tiny change of behavior so I wanted to point it out. Ah yes, it would have made sense to point out. I was wondering about this check. It was introduced to bail on compaction if there are not enough free non-CMA pages. But if there are, we still fall through and check the superset of regular + CMA pages against the watermarks as well. We know this will succeed, so this seems moot. It's also a little odd that compaction_suitable() hardcodes ALLOC_CMA with the explanation that "CMA are migration targets", but then this check says "actually, it doesn't help us if blocks are formed in CMA". Does it make more sense to plumb alloc_flags to compaction_suitable()? There is more head-scratching, though. The check is meant to test whether compaction has a chance of forming non-CMA blocks. But free pages are targets. You could have plenty of non-contiguous, free non-CMA memory - compaction will then form blocks in CMA by moving CMA pages into those non-CMA targets. The longer I look at this, the more I feel like this just hard-coded the very specific scenario the patch author had a problem with: CMA is massive. The page allocator fills up regular memory first. Once regular memory is full, non-CMA requests stall on compaction making CMA blocks. So just bail on compaction then. It's a valid problem, but I don't see how this code makes any general sense outside of this exact sequence of events. Especially once compaction has moved stuff around between regular and CMA memory, the issue will be back, and the check does nothing to prevent it.