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 ECBCBC3601E for ; Thu, 10 Apr 2025 08:06:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8629280081; Thu, 10 Apr 2025 04:06:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E366D280086; Thu, 10 Apr 2025 04:06:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C84D9280081; Thu, 10 Apr 2025 04:06:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id AB4B228007D for ; Thu, 10 Apr 2025 04:06:36 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BD9891605D9 for ; Thu, 10 Apr 2025 08:06:37 +0000 (UTC) X-FDA: 83317402434.17.77F829C Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf24.hostedemail.com (Postfix) with ESMTP id A2C4F180010 for ; Thu, 10 Apr 2025 08:06:34 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf24.hostedemail.com: domain of tujinjiang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=tujinjiang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744272396; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ws+c9i5aSvNY0G6FobHuGrBDvCZEE4WV58rVbv2n6gQ=; b=S3Zv50iLTTduxrmqBwhNzmC11jJs837vhPtjxN+Bm7SXXolVwnJc5p39g5nOhIQ2NTKkRE YoWz5CmHnTu8axD75+fp8EJw6xX7qLpmIpGmnnnbgiaCe/KHI+RrjItV+nXTESmmra+kg8 0CdZzGeIeNLRcgAgd0gtAq/RWELJUJI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf24.hostedemail.com: domain of tujinjiang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=tujinjiang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744272396; a=rsa-sha256; cv=none; b=AtTCzJ9ULOrFDNxRLddBsziy5osmzEPjAY4laPXYTeDOnsbmA6qYMFs9SSJqYeqneztCK6 iml2VEucwJEpDHMtE0GLKA2j7cEhPxzQ6QIhuqTqpxdBreJf0HFsMl0OkRt0PjhMPmKQl6 C0x2+QUUPRX9TRY0G5qVreuBEAZkV4c= Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4ZYC6B58NQznfYw; Thu, 10 Apr 2025 16:05:06 +0800 (CST) Received: from kwepemo200002.china.huawei.com (unknown [7.202.195.209]) by mail.maildlp.com (Postfix) with ESMTPS id 52F131402EB; Thu, 10 Apr 2025 16:06:30 +0800 (CST) Received: from [10.174.179.13] (10.174.179.13) by kwepemo200002.china.huawei.com (7.202.195.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 10 Apr 2025 16:06:29 +0800 Message-ID: <2699b9d3-595e-2640-6b53-298ba835f929@huawei.com> Date: Thu, 10 Apr 2025 16:06:28 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH V4] mm/gup: Clear the LRU flag of a page before adding to LRU batch To: David Hildenbrand , , CC: , , , <21cnbao@gmail.com>, , , , Kefeng Wang References: <1720075944-27201-1-git-send-email-yangge1116@126.com> <4119c1d0-5010-b2e7-3f1c-edd37f16f1f2@huawei.com> <91ac638d-b2d6-4683-ab29-fb647f58af63@redhat.com> <076babae-9fc6-13f5-36a3-95dde0115f77@huawei.com> <26870d6f-8bb9-44de-9d1f-dcb1b5a93eae@redhat.com> <5d0cb178-6436-d98b-3abf-3bcf8710eb6f@huawei.com> <207a00a2-0895-4086-97ae-d31ead423cf8@redhat.com> From: Jinjiang Tu In-Reply-To: <207a00a2-0895-4086-97ae-d31ead423cf8@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.13] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemo200002.china.huawei.com (7.202.195.209) X-Rspamd-Queue-Id: A2C4F180010 X-Rspamd-Server: rspam05 X-Rspam-User: X-Stat-Signature: dxu9ofs7fh53k5r91wrz9okfp458ua6c X-HE-Tag: 1744272394-521492 X-HE-Meta: U2FsdGVkX18SISKIOG7ody2ubDC1DnuB5C0RRe/jQs+dfsCxHV23/fQq0YytC7Xjb4zZxUqrb6GYdSbEa+o3BbZ37duDWdxMrL5zQFUof9++Kbe9r1hibRTZaVaZSp4CNXnXwp3VcLlkpScONkt+L2fUOGV6jRWGQz2E8pp2PPk8PxUBkjkgf7I8sg7DTo6qFqYoT/9USHj0RZHGON6Yi9U5MaiJRVetdI1yiM/tolOndcHSLibhTYLZhpzgVNnnwu4qjRXFNKyqAWboa9czN7N3tzQIeTYH2EOB9EvSQk3KbORgQ4IPPznonYV6OBCqLzv/n2LnhcZPyaS39PBCEEwuDheU7s5oB6fUhmM3QwRr/ZPcUe526DsgPr8E78JhELlNDu4VXCbB3SoNfxd56BqOK+DzOk1mUHYaVFc2+u69Ij0qihw7Y2ZPrcA+6OHh+wsuvVb8mx8pX4MaVkA8HW1+a6GWH+KmWZyN20QiqL2hyYCFpCvwYENDOqbeXVH1A3t0zKmGk6BghKPaTSYdEw9GbwRYigvhO613Ba3vDpzCGD/X4ErqQ5Dg01tC2WSk3oTzFXBCeg+n8bjXzTmMUKZHn/OQ216+RPg5u4cMfcHPKW8UtaZWLSx3wSe5YJeoyfcpeephkI/6MBFqh2O65XFbyqgaBVyXo2DtkYmhVJJZ7F27Ck1jn/CkXRpeJThuosHZRWJC/7p1WkYjj2be2CEONPtyO+4X2t8Y0hdmZttetWzMA/uShBOSH4jnYjm+5VqkFs/OKr28nkdhR/ozi+9R8l2BPiluBym5x2t6GUHXNHnjbgNm3FPjCB0IFyvtREvKpkwLufQNT5sZdd3MDYJKaY5M1fSK0aPkdkX7Gdc3QgdKvnadhm4OUROPgMM2MuaQ9tPCXZZaxKKjx87QywvFh4lsSZkbcCHxwbBwiduJPh59d1/m9HTDANHIq7ABIQJm0zKU1Dxry4lKcFN /F68EkoB hiw6rEh7+3+zXQ4JTUbTmaHRwMgQHdhPUbxtpVrW4eGOkl1UeZGVnovw3Dn7LO+ExK0//f/Bu3Rn8StE4aID17no++tA2Dh4yEUVYHtTZmtw6Z+htvuifuVRjRbv+FIESe1gNLf1jdu752zO0TAEXfHHIwY9Eeei3ogmII7ddb2oELu0fWkv2VWvcLaliCgImBZQPz8cE3hsE3hEDy4u5qP/QsQ== 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: List-Subscribe: List-Unsubscribe: 在 2025/4/8 18:04, David Hildenbrand 写道: > On 08.04.25 10:47, Jinjiang Tu wrote: >> >> 在 2025/4/1 22:33, David Hildenbrand 写道: >>> On 27.03.25 12:16, Jinjiang Tu wrote: >>>> >>>> 在 2025/3/26 20:46, David Hildenbrand 写道: >>>>> On 26.03.25 13:42, Jinjiang Tu wrote: >>>>>> Hi, >>>>>> >>>>> >>>>> Hi! >>>>> >>>>>> We notiched a 12.3% performance regression for LibMicro pwrite >>>>>> testcase due to >>>>>> commit 33dfe9204f29 ("mm/gup: clear the LRU flag of a page before >>>>>> adding to LRU batch"). >>>>>> >>>>>> The testcase is executed as follows, and the file is tmpfs file. >>>>>>        pwrite -E -C 200 -L -S -W -N "pwrite_t1k" -s 1k -I 500 -f >>>>>> $TFILE >>>>> >>>>> Do we know how much that reflects real workloads? (IOW, how much >>>>> should we care) >>>> >>>> No, it's hard to say. >>>> >>>>> >>>>>> >>>>>> this testcase writes 1KB (only one page) to the tmpfs and repeats >>>>>> this step for many times. The Flame >>>>>> graph shows the performance regression comes from >>>>>> folio_mark_accessed() and workingset_activation(). >>>>>> >>>>>> folio_mark_accessed() is called for the same page for many times. >>>>>> Before this patch, each call will >>>>>> add the page to cpu_fbatches.activate. When the fbatch is full, the >>>>>> fbatch is drained and the page >>>>>> is promoted to active list. And then, folio_mark_accessed() does >>>>>> nothing in later calls. >>>>>> >>>>>> But after this patch, the folio clear lru flags after it is added to >>>>>> cpu_fbatches.activate. After then, >>>>>> folio_mark_accessed will never call folio_activate() again due to >>>>>> the >>>>>> page is without lru flag, and >>>>>> the fbatch will not be full and the folio will not be marked active, >>>>>> later folio_mark_accessed() >>>>>> calls will always call workingset_activation(), leading to >>>>>> performance regression. >>>>> >>>>> Would there be a good place to drain the LRU to effectively get that >>>>> processed? (we can always try draining if the LRU flag is not set) >>>> >>>> Maybe we could drain the search the cpu_fbatches.activate of the >>>> local cpu in __lru_cache_activate_folio()? Drain other fbatches is >>>> meaningless . >>> >>> So the current behavior is that folio_mark_accessed() will end up >>> calling folio_activate() >>> once, and then __lru_cache_activate_folio() until the LRU was drained >>> (which can >>> take a looong time). >>> >>> The old behavior was that folio_mark_accessed() would keep calling >>> folio_activate() until >>> the LRU was drained simply because it was full of "all the same pages" >>> ?. Only *after* >>> the LRU was drained, folio_mark_accessed() would actually not do >>> anything (desired behavior). >>> >>> So the overhead comes primarily from __lru_cache_activate_folio() >>> searching through >>> the list "more" repeatedly because the LRU does get drained less >>> frequently; and >>> it would never find it in there in this case. >>> >>> So ... it used to be suboptimal before, now it's more suboptimal I >>> guess?! :) >>> >>> We'd need a way to better identify "this folio is already queued for >>> activation". Searching >>> that list as well would be one option, but the hole "search the list" >>> is nasty. >>> >>> Maybe we can simply set the folio as active when staging it for >>> activation, after having >>> cleared the LRU flag? We already do that during folio_add. >>> >>> As the LRU flag was cleared, nobody should be messing with that folio >>> until the cache was >>> drained and the move was successful. >>> >>> >>> Pretty sure this doesn't work, but just to throw out an idea: >>> >>>  From c26e1c0ceda6c818826e5b89dc7c7c9279138f80 Mon Sep 17 00:00:00 2001 >>> From: David Hildenbrand >>> Date: Tue, 1 Apr 2025 16:31:56 +0200 >>> Subject: [PATCH] test >>> >>> Signed-off-by: David Hildenbrand >>> --- >>>   mm/swap.c | 21 ++++++++++++++++----- >>>   1 file changed, 16 insertions(+), 5 deletions(-) >>> >>> diff --git a/mm/swap.c b/mm/swap.c >>> index fc8281ef42415..bbf9aa76db87f 100644 >>> --- a/mm/swap.c >>> +++ b/mm/swap.c >>> @@ -175,6 +175,8 @@ static void folio_batch_move_lru(struct >>> folio_batch *fbatch, move_fn_t move_fn) >>>       folios_put(fbatch); >>>   } >>> >>> +static void lru_activate(struct lruvec *lruvec, struct folio *folio); >>> + >>>   static void __folio_batch_add_and_move(struct folio_batch __percpu >>> *fbatch, >>>           struct folio *folio, move_fn_t move_fn, >>>           bool on_lru, bool disable_irq) >>> @@ -191,6 +193,10 @@ static void __folio_batch_add_and_move(struct >>> folio_batch __percpu *fbatch, >>>       else >>>           local_lock(&cpu_fbatches.lock); >>> >>> +    /* We'll only perform the actual list move deferred. */ >>> +    if (move_fn == lru_activate) >>> +        folio_set_active(folio); >>> + >>>       if (!folio_batch_add(this_cpu_ptr(fbatch), folio) || >>> folio_test_large(folio) || >>>           lru_cache_disabled()) >>>           folio_batch_move_lru(this_cpu_ptr(fbatch), move_fn); >>> @@ -299,12 +305,14 @@ static void lru_activate(struct lruvec *lruvec, >>> struct folio *folio) >>>   { >>>       long nr_pages = folio_nr_pages(folio); >>> >>> -    if (folio_test_active(folio) || folio_test_unevictable(folio)) >>> -        return; >>> - >>> +    /* >>> +     * We set the folio active after clearing the LRU flag, and set >>> the >>> +     * LRU flag only after moving it to the right list. >>> +     */ >>> +    VM_WARN_ON_ONCE(!folio_test_active(folio)); >>> +    VM_WARN_ON_ONCE(folio_test_unevictable(folio)); >>> >>>       lruvec_del_folio(lruvec, folio); >>> -    folio_set_active(folio); >>>       lruvec_add_folio(lruvec, folio); >>>       trace_mm_lru_activate(folio); >>> >>> @@ -342,7 +350,10 @@ void folio_activate(struct folio *folio) >>>           return; >>> >>>       lruvec = folio_lruvec_lock_irq(folio); >>> -    lru_activate(lruvec, folio); >>> +    if (!folio_test_unevictable(folio)) { >>> +        folio_set_active(folio); >>> +        lru_activate(lruvec, folio); >>> +    } >>>       unlock_page_lruvec_irq(lruvec); >>>       folio_set_lru(folio); >>>   } >> >> I test with the patch, and the performance regression disappears. >> >> By the way, I find folio_test_unevictable() is called in >> lru_deactivate, lru_lazyfree, etc. >> unevictable flag is set when the caller clears lru flag. IIUC, since >> commit 33dfe9204f29 ("mm/gup: clear the LRU flag of a page before >> adding to LRU batch"), folios in fbatch can't be set unevictable >> flag, so there is no need to check unevictable flag in >> lru_deactivate, lru_lazyfree, etc? > > I was asking myself the exact same question when crafting this patch. > Sounds like a cleanup worth investigating! :) folio_activate __mlock_folio folio_test_unevictable folio_test_clear_lru folio_set_unevictable folio_set_lru folio_batch_add_and_move folio_test_clear_lru In the above case, unevictable flag will be set before lru flag is cleared in folio_activate(). So folio may still be unevictable in lru_activate(). > > Do you have capacity to look into that, and to turn my proposal into a > proper patch? It might take me a bit until I get to it. >