From patchwork Tue Apr 18 16:58:54 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 13215941 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 B7FE4C77B75 for ; Tue, 18 Apr 2023 16:59:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E7D68E0002; Tue, 18 Apr 2023 12:59:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3980A8E0001; Tue, 18 Apr 2023 12:59:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25FC78E0002; Tue, 18 Apr 2023 12:59:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 199638E0001 for ; Tue, 18 Apr 2023 12:59:23 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DE0E9802AF for ; Tue, 18 Apr 2023 16:59:22 +0000 (UTC) X-FDA: 80695122564.02.04BCFD8 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf09.hostedemail.com (Postfix) with ESMTP id 1C7A214000B for ; Tue, 18 Apr 2023 16:59:20 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=XKJ57OQq; spf=pass (imf09.hostedemail.com: domain of dianders@chromium.org designates 209.85.214.180 as permitted sender) smtp.mailfrom=dianders@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681837161; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=6+Cu265ve+v/mYTevQG7B1gRVZEieX1Qo5P1wD9Qx14=; b=y+ncYCcehjfMJRTUlW1S2jMsKJIxQfBGOxLYKi5PrWRycC7Wk+XW0p5d6Od8EH6+BpVLrA /nEUPyQ7Rhl3Vqo3h30xwey/fKsFJK+Xma8P2Dg5HPzQvscQbOxfkmvjpakbUhzFX1WSUf mL1speqWdVRTVHUBG0NgwziZ2JN29QQ= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=XKJ57OQq; spf=pass (imf09.hostedemail.com: domain of dianders@chromium.org designates 209.85.214.180 as permitted sender) smtp.mailfrom=dianders@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681837161; a=rsa-sha256; cv=none; b=3Z3eC7bMJMacOgXruAPSgH7VwMgZp5ht0S12BI3VRIfijgcPofvRtZJuDeTyG3IHNNFzQh uY+FGk8nc3B2LGBqgOSom1cIWVhLLf6BdyzTzAdb3WbQvwlISb9sBJPm4jyDgHtixZ/fG7 ANrd7KUwucsbSIlBpvlWrOgWcw3ewsk= Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-1a667067275so18799135ad.1 for ; Tue, 18 Apr 2023 09:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1681837160; x=1684429160; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=6+Cu265ve+v/mYTevQG7B1gRVZEieX1Qo5P1wD9Qx14=; b=XKJ57OQqx/2PUHBsVuJiKQWKGxI0zf38e+uy5+3VzxmqWT5D9CoR9d/c3NX3CPvdvm tsgZ6wXl9/jMJbsaEYrw+C5mAR0OeNteAq7KXdnzEKsYopxMIY0VbeAXnjWrgKmmQLvy g2J7T3XZsbWjZKBQL8Hn4B+80abDhZ8JayM+E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681837160; x=1684429160; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6+Cu265ve+v/mYTevQG7B1gRVZEieX1Qo5P1wD9Qx14=; b=ZsOedXwh5L5/MEj0nLx+XO7eubOb/IRy8p3uWNXncz+8KFhjK2LD9MM59i4356m17v YTcL0onvggQgCdCySoGEJB8K182RbT8FmwRKmCEdxAMjCA3j93WtdQPqEvUtYkuWlapb kpn0hqUV9PMN6HOpOaaldM5tepU/DG543lzW664V1pz+ogFNrljL6ChgYNGTBTsymyo8 LS0qG0ZQiRLFayxHT27I96IzT3PhX1WHDJ+T2P9dSsHUs/vUYW976lZlF2OUcMGrJPE0 3iIYqEEOJHMtRzhWtn/DNm0twynjoTTfpzSFxuHSMPtH8pXaL+QqYL3KBV5KeG+kwtqJ xTsA== X-Gm-Message-State: AAQBX9cPOpaVMW6ijILxNwdcxolINSUMXthA+XUaSPdysHaKWZLL2ok0 Q/CzbuHKWJ1aD1/mkmfWPA8i9w== X-Google-Smtp-Source: AKy350ZOEbHETwSEaZ9aaPXnM/w14ni5nkHS+Z3blNn8sd9VN/rBzsneJLLLBdUDfsOIvzVqBV9T7A== X-Received: by 2002:a17:903:280d:b0:1a5:31f2:9036 with SMTP id kp13-20020a170903280d00b001a531f29036mr2645410plb.11.1681837159865; Tue, 18 Apr 2023 09:59:19 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:15a7:1899:efc0:f521]) by smtp.gmail.com with ESMTPSA id b6-20020a170902bd4600b001a216d44440sm9829786plx.200.2023.04.18.09.59.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Apr 2023 09:59:19 -0700 (PDT) From: Douglas Anderson To: Andrew Morton Cc: Vlastimil Babka , Mel Gorman , Yu Zhao , Ying , Johannes Weiner , Douglas Anderson , "Peter Zijlstra (Intel)" , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH] mm, compaction: kcompactd work shouldn't count towards memory PSI Date: Tue, 18 Apr 2023 09:58:54 -0700 Message-ID: <20230418095852.RFC.1.I53bf7f0c7d48fe7af13c5dd3ad581d3bcfd9d1bd@changeid> X-Mailer: git-send-email 2.40.0.634.g4ca3ef3211-goog MIME-Version: 1.0 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1C7A214000B X-Rspam-User: X-Stat-Signature: 43fqqsoi8w1phh3hw4ch4dk4jiy8dmr3 X-HE-Tag: 1681837160-553902 X-HE-Meta: U2FsdGVkX18zZjFFHwAptzgS2WTs1bGHMs2HbgCHgj7SvbGq2AfIVnia6QE/NjiY5f+uJedNqFcvTqrJWHZ1ZJ+DN5bgRHwA1rTcJ2+CPieawiwXp1agjDPfV+sYsQ3wOdvcdg9WBHxsSvtO6InehGA06Ff8kPUELsAhr+mKvBazNRRn8PsPJsIDZhzFP8G9EA2n4+lcPUcTak0Rks2fPA9KpkVESEiVfd79QRmRojitalj2l2MJnDO32OSKmUQdbfLB3TwG7F89ki6zFv4dTV+lgTuhCCkmOMzPY6Gv45+6cQkGWi/MLC5FX2D6chR+/yrjTXnw5MSQNHJkEsr8enXZyKgzM0MwuBDBKusHFYLaO5GM9gZJKYdx631O7Ezjr3U+g8yR+BCvcDKQh6HesjovmekdDoHuTMeRUR8MYqgM9aVFdr4EWgEmLP2zcuOSOLccEFzr//EbdUFx56I2HcDEhsb8Q5JDId1UJASTWjMn6uP4t5xhod1426+X0wmWQV0DPjfcaTCAqx2mMHXGzZ2q0VNkFydnBVkbV8fep83iZx5jdLAxPPrfIr5eB05fRItSsL6st6JwuJk4U4iZ3AwgiI3/fRpFscEsmCGvLAgd2inA0CUjzb5VgmOb1USd2agtCCZXRXcjM1NLWEGagxishcyr/2UubLa5yIBTY4MGbBdq+jAgIC+AX4NriBiAttCJW2eBX2phfHKK8BAFoJ6pDl0erf8Ra0IX8qYx5x0N51vUZAOhXMCag979ZD1FGeLDlnz0KC/T0oVg32ixbfdZqe6TRsJyPrdaG9PyOPR4o35akw4Jm9eRu0KRAR6BGOrUYohoGh5cRAkkEJ5gjyjAfuohoOrlYSrTfNzPP4oPgI3IqfDWI1zcuBBau5cKD5z7ljXm8g/7b4ceKF0KHl9gnRdRRDlXDVJThyu9tFIFfl/OgNV12V0HABug7xwBLb0qNj/os3omQqKdM6v jVO9Ojjo 2VUAS1h0/oPaLW1Q68kxMTVBbbO15IyZvtxzoGAnJLwhQTLb6rMgMzUeGzfPjTIgZPr0+EuwrSv7D1PY2FiNfDF/1th1iG/RnitFui1FghC1tg6ubMikpCgBEn0cUPNjCDLfOi1Ytfu0cjYISvyTzpyB8s4yp8hI4d9qzL8lKwJlhCAgtV06nUNjEItf92NUacUplOJInpYE+ys8mr9UM9FZBUbUYvvJ0ZX59dxHqsEMF16XbFg6c9GH6AAVyMSXJFm838AQCLvqtRcfDXFSLT7SI0+HIYaTiWI+uzM4wiaEzPG72uN6ZQ1lXWEz+5sDcvc+/vzfws555eLMIHqye5Jx3E5zYzC0IUNSF+plrtSamg3neNzlAaFFVT7cTnNDx6TuNxC5MtCS1pYfMYWTlMBQ5jSWnurcBKcEIsAGp1eejkwb9cYSEx5FhBZ8sCoNRsRqLgOAGO5L2kgHUFcyLQmmYtJi73Rme3FQh/WJmgzMVCr0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: When the main kcompactd thread is doing compaction then it's always proactive compaction. This is a little confusing because kcompactd has two phases and one of them is called the "proactive" phase. Specifically: * Phase 1 (the "non-proactive" phase): we've been told by someone else that it would be a good idea to try to compact memory. * Phase 2 (the "proactive" phase): we analyze memory fragmentation ourselves and compact if it looks fragmented. From the context of kcompactd, the above naming makes sense. However, from the context of the kernel as a whole both phases are "proactive" because in both cases we're trying compact memory ahead of time and we're not actually blocking (stalling) any task who is trying to use memory. Specifically, if any task is actually blocked needing memory to be compacted then it will be in direct reclaim. That won't block waiting on kcompactd task but instead call try_to_compact_pages() directly. The caller of that direct compaction, __alloc_pages_direct_compact(), already marks itself as counting towards PSI. Sanity checking by looking at this from another perspective, we can look at all the people who explicitly ask kcompactd to do a reclaim by calling wakeup_kcompactd(). That leads us to 3 places in vmscan.c. Those are all requests from kswapd, which is also a "proactive" mechanism in the kernel (tasks aren't blocked waiting for it). Fixes: eb414681d5a0 ("psi: pressure stall information for CPU, memory, and IO") Signed-off-by: Douglas Anderson --- I stumbled upon this while researching for a different patch [1]. Although both the other patch and this one affect kcompactd, they are otherwise unrelated. It can be noted that ${SUBJECT} patch was created solely by code inspection. I don't have any specific test cases that are made better by it, the code just didn't seem quite right to me. My knowledge of the memory subsystem is shaky at best, so please take this patch with a grain of salt. If you're a memory system expert and this patch looks totally misguided to you then it probably is. ;-) [1] https://lore.kernel.org/r/20230413182313.RFC.1.Ia86ccac02a303154a0b8bc60567e7a95d34c96d3@changeid mm/compaction.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/mm/compaction.c b/mm/compaction.c index 5a9501e0ae01..5a8d78b506e4 100644 --- a/mm/compaction.c +++ b/mm/compaction.c @@ -22,7 +22,6 @@ #include #include #include -#include #include "internal.h" #ifdef CONFIG_COMPACTION @@ -2954,8 +2953,6 @@ static int kcompactd(void *p) pgdat->kcompactd_highest_zoneidx = pgdat->nr_zones - 1; while (!kthread_should_stop()) { - unsigned long pflags; - /* * Avoid the unnecessary wakeup for proactive compaction * when it is disabled. @@ -2967,9 +2964,8 @@ static int kcompactd(void *p) kcompactd_work_requested(pgdat), timeout) && !pgdat->proactive_compact_trigger) { - psi_memstall_enter(&pflags); kcompactd_do_work(pgdat); - psi_memstall_leave(&pflags); + /* * Reset the timeout value. The defer timeout from * proactive compaction is lost here but that is fine