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 F31D6C3600B for ; Wed, 26 Mar 2025 12:42:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 610C228007B; Wed, 26 Mar 2025 08:42:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 59A8D280069; Wed, 26 Mar 2025 08:42:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43D3B28007B; Wed, 26 Mar 2025 08:42:39 -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 215C6280069 for ; Wed, 26 Mar 2025 08:42:39 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 640F71408EC for ; Wed, 26 Mar 2025 12:42:40 +0000 (UTC) X-FDA: 83263666080.18.0B95FEB Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf30.hostedemail.com (Postfix) with ESMTP id 926478000C for ; Wed, 26 Mar 2025 12:42:37 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf30.hostedemail.com: domain of tujinjiang@huawei.com designates 45.249.212.187 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=1742992958; 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=SDxM5pvWTu61axMjyWWXp3X/rIHlu0H22fKdTFsUmck=; b=66apOiUo70Qu1aZX/MKDZLe74cY4/Qi1z+wQ64use95fZBDCGB0u752wMo7e0stzaN5EaN OVX6lMkEn3Kvlctg77wY22WBfxYgy8urHdqZ/Lso+xzfItxLrEPovewmMOj9DIK+dUeGh0 vvywF4U43IYSrunnqmquMDgTeOX121I= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf30.hostedemail.com: domain of tujinjiang@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=tujinjiang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742992958; a=rsa-sha256; cv=none; b=3s5gzzdsq6jZy0b8XK75ciEg6qSHQyyM1Q9uCBkwUIUBA1iZOBdUeSXAEMJfGQNJgoUWHL N75+E+8I2ILFABPoJV/eWUWjc/EPoV/Rzz7bPWMxMlG1N8mOcFgn96Ap0EKmFvrlhPjc58 2XysOO0ta4v7DuRgpowwEBPRw1P6+m4= Received: from mail.maildlp.com (unknown [172.19.88.194]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4ZN5th4xjjzvWpl; Wed, 26 Mar 2025 20:38:36 +0800 (CST) Received: from kwepemo200002.china.huawei.com (unknown [7.202.195.209]) by mail.maildlp.com (Postfix) with ESMTPS id 7D8251400F4; Wed, 26 Mar 2025 20:42:33 +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; Wed, 26 Mar 2025 20:42:32 +0800 Message-ID: <4119c1d0-5010-b2e7-3f1c-edd37f16f1f2@huawei.com> Date: Wed, 26 Mar 2025 20:42:31 +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: , CC: , , , <21cnbao@gmail.com>, , , , , Kefeng Wang References: <1720075944-27201-1-git-send-email-yangge1116@126.com> From: Jinjiang Tu In-Reply-To: <1720075944-27201-1-git-send-email-yangge1116@126.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.13] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemo200002.china.huawei.com (7.202.195.209) X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 926478000C X-Stat-Signature: sjpxdmrf6za15w9hdufoh7wifi9zwgyt X-HE-Tag: 1742992957-761753 X-HE-Meta: U2FsdGVkX19bHzC0qU83C3XOWSsZbCG8+Znqr7W6Ue9s1bQtTHeC9IYjNZq7QWJsLXHqmuHp59ZoIxr2Uyb6cKocuZnkJhw+GFwzgKqubIolRdF+9a5JCRW9D43V2VlvpyWPQehyq4JIJmUb20xnONCwGg3xMWbY6xQ0DBtuv9CFACZpswi9fReLIK5zK2I4qHxX2kCSHVTgPblP6KdbzqRevrEdYIvEEEil77IJC9lZVovY2+um58mEfvVo2svvVZvphMFZD4M3j18S8bqQNZRZhspsJmkBq0GpoYK59+3Fz9Jfhu0XLi4IlyKPEL6iG7DZUN5NOAK4LCeezq3e+btqEt/3a0DjO3Tl6k75THPahcf0Dpzl80dHl0Q/0vn3eu6qrXd4HmaVh3hpPDCdzOzonknqNO+uHVPdelq9iuBQB5WY8LutKmLSOgDq0V8NlFqQGXPcG5qwoEAngcjtpaCUwqsXRms/l/wHjpYbTahPFE7GZU6xQ6CdYomrWfpqTRMaUWjC7urJ9f1P+h+AvqnLRuvvFiH+KwbNFdgk+3rLY/DL20/Br48QMiUelckk8+w3jgn+RnXyMb4KLpQOpnMqlLQYO+K8D7Mb5uHOXmnjbvc1a9hnwNTR0CO2YqG2eHTU/Zv6iUKsg+B1HeDV/47erKRMHPxIVP9CVqio1GvQIO7i7dH26WWOKiZ0uYUHBL6sEGqIZ/uqO0MTqzQun3o9rSqh/WY4Cln/+e9Xky2c1wRmMIJ1KuIWc23RXFxGh2VT8JEs9o/JhhL9g3TSshYXQWR2iGyZBETY9+hw6QqnjB7auEycl6lKY8W9Bh1fgIBtnlW2B5eDbzRhqeQSbjoSjOidxD9FNymUGxTweEfcyczVpA3a7qQbq6bfWfTj37Qtg4eV1Y68OvmsQ3FMEK5fOokR5o1OQuqzoHRDdkns7kxRgKZGByPGcYOWMv+Wx+POdPntokR+oZqFZEi uuFQK2Po NJjLtquiXEu/QXvjJn33+dbGmkl/3Vp70kBG1MgEOL4t2EQckrjTRPQDgFMulAu29u8P3MJIrNSBbtTokFHWRclar/rfWPIh487kp2q++ORdKvuqQnnGq7Up+YmrwrVf2zJy4YU00N3hVJeixKM5eOexw5GumTddbqda1aYnCeeCavRfwLPhPtAdI7113R2m/l3C5S3KYsvO5Bbw1aIGAVOjonYXebXqTx6NHpxPSHVo4SFRY1/6Vhg3KbAg6PY7WJbKGcfm0X5UTo9E= 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: 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 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. In addition, folio_mark_accessed() calls __lru_cache_activate_folio(). This function does as follow comments: /* * Search backwards on the optimistic assumption that the folio being * activated has just been added to this batch. */ However, after this patch, folio without lru flag may be in other fbatch too, such as cpu_fbatches.activate. 在 2024/7/4 14:52, yangge1116@126.com 写道: > From: yangge > > If a large number of CMA memory are configured in system (for example, the > CMA memory accounts for 50% of the system memory), starting a virtual > virtual machine with device passthrough, it will > call pin_user_pages_remote(..., FOLL_LONGTERM, ...) to pin memory. > Normally if a page is present and in CMA area, pin_user_pages_remote() > will migrate the page from CMA area to non-CMA area because of > FOLL_LONGTERM flag. But the current code will cause the migration failure > due to unexpected page refcounts, and eventually cause the virtual machine > fail to start. > > If a page is added in LRU batch, its refcount increases one, remove the > page from LRU batch decreases one. Page migration requires the page is not > referenced by others except page mapping. Before migrating a page, we > should try to drain the page from LRU batch in case the page is in it, > however, folio_test_lru() is not sufficient to tell whether the page is > in LRU batch or not, if the page is in LRU batch, the migration will fail. > > To solve the problem above, we modify the logic of adding to LRU batch. > Before adding a page to LRU batch, we clear the LRU flag of the page so > that we can check whether the page is in LRU batch by folio_test_lru(page). > It's quite valuable, because likely we don't want to blindly drain the LRU > batch simply because there is some unexpected reference on a page, as > described above. > > This change makes the LRU flag of a page invisible for longer, which > may impact some programs. For example, as long as a page is on a LRU > batch, we cannot isolate it, and we cannot check if it's an LRU page. > Further, a page can now only be on exactly one LRU batch. This doesn't > seem to matter much, because a new page is allocated from buddy and > added to the lru batch, or be isolated, it's LRU flag may also be > invisible for a long time. > > Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region") > Cc: > Signed-off-by: yangge > --- > mm/swap.c | 43 +++++++++++++++++++++++++++++++------------ > 1 file changed, 31 insertions(+), 12 deletions(-) > > V4: > Adjust commit message according to David's comments > V3: > Add fixes tag > V2: > Adjust code and commit message according to David's comments > > diff --git a/mm/swap.c b/mm/swap.c > index dc205bd..9caf6b0 100644 > --- a/mm/swap.c > +++ b/mm/swap.c > @@ -211,10 +211,6 @@ static void folio_batch_move_lru(struct folio_batch *fbatch, move_fn_t move_fn) > for (i = 0; i < folio_batch_count(fbatch); i++) { > struct folio *folio = fbatch->folios[i]; > > - /* block memcg migration while the folio moves between lru */ > - if (move_fn != lru_add_fn && !folio_test_clear_lru(folio)) > - continue; > - > folio_lruvec_relock_irqsave(folio, &lruvec, &flags); > move_fn(lruvec, folio); > > @@ -255,11 +251,16 @@ static void lru_move_tail_fn(struct lruvec *lruvec, struct folio *folio) > void folio_rotate_reclaimable(struct folio *folio) > { > if (!folio_test_locked(folio) && !folio_test_dirty(folio) && > - !folio_test_unevictable(folio) && folio_test_lru(folio)) { > + !folio_test_unevictable(folio)) { > struct folio_batch *fbatch; > unsigned long flags; > > folio_get(folio); > + if (!folio_test_clear_lru(folio)) { > + folio_put(folio); > + return; > + } > + > local_lock_irqsave(&lru_rotate.lock, flags); > fbatch = this_cpu_ptr(&lru_rotate.fbatch); > folio_batch_add_and_move(fbatch, folio, lru_move_tail_fn); > @@ -352,11 +353,15 @@ static void folio_activate_drain(int cpu) > > void folio_activate(struct folio *folio) > { > - if (folio_test_lru(folio) && !folio_test_active(folio) && > - !folio_test_unevictable(folio)) { > + if (!folio_test_active(folio) && !folio_test_unevictable(folio)) { > struct folio_batch *fbatch; > > folio_get(folio); > + if (!folio_test_clear_lru(folio)) { > + folio_put(folio); > + return; > + } > + > local_lock(&cpu_fbatches.lock); > fbatch = this_cpu_ptr(&cpu_fbatches.activate); > folio_batch_add_and_move(fbatch, folio, folio_activate_fn); > @@ -700,6 +705,11 @@ void deactivate_file_folio(struct folio *folio) > return; > > folio_get(folio); > + if (!folio_test_clear_lru(folio)) { > + folio_put(folio); > + return; > + } > + > local_lock(&cpu_fbatches.lock); > fbatch = this_cpu_ptr(&cpu_fbatches.lru_deactivate_file); > folio_batch_add_and_move(fbatch, folio, lru_deactivate_file_fn); > @@ -716,11 +726,16 @@ void deactivate_file_folio(struct folio *folio) > */ > void folio_deactivate(struct folio *folio) > { > - if (folio_test_lru(folio) && !folio_test_unevictable(folio) && > - (folio_test_active(folio) || lru_gen_enabled())) { > + if (!folio_test_unevictable(folio) && (folio_test_active(folio) || > + lru_gen_enabled())) { > struct folio_batch *fbatch; > > folio_get(folio); > + if (!folio_test_clear_lru(folio)) { > + folio_put(folio); > + return; > + } > + > local_lock(&cpu_fbatches.lock); > fbatch = this_cpu_ptr(&cpu_fbatches.lru_deactivate); > folio_batch_add_and_move(fbatch, folio, lru_deactivate_fn); > @@ -737,12 +752,16 @@ void folio_deactivate(struct folio *folio) > */ > void folio_mark_lazyfree(struct folio *folio) > { > - if (folio_test_lru(folio) && folio_test_anon(folio) && > - folio_test_swapbacked(folio) && !folio_test_swapcache(folio) && > - !folio_test_unevictable(folio)) { > + if (folio_test_anon(folio) && folio_test_swapbacked(folio) && > + !folio_test_swapcache(folio) && !folio_test_unevictable(folio)) { > struct folio_batch *fbatch; > > folio_get(folio); > + if (!folio_test_clear_lru(folio)) { > + folio_put(folio); > + return; > + } > + > local_lock(&cpu_fbatches.lock); > fbatch = this_cpu_ptr(&cpu_fbatches.lru_lazyfree); > folio_batch_add_and_move(fbatch, folio, lru_lazyfree_fn);