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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F5C3CDB482 for ; Thu, 19 Oct 2023 08:51:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235187AbjJSIvD (ORCPT ); Thu, 19 Oct 2023 04:51:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232935AbjJSIvB (ORCPT ); Thu, 19 Oct 2023 04:51:01 -0400 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D70AC12A for ; Thu, 19 Oct 2023 01:50:58 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046049;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0VuTS0kE_1697705454; Received: from 30.97.48.56(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0VuTS0kE_1697705454) by smtp.aliyun-inc.com; Thu, 19 Oct 2023 16:50:55 +0800 Message-ID: Date: Thu, 19 Oct 2023 16:51:08 +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] mm: migrate: record the mlocked page status to remove unnecessary lru drain To: Yin Fengwei , "Huang, Ying" , Zi Yan Cc: akpm@linux-foundation.org, mgorman@techsingularity.net, hughd@google.com, vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <64899ad0bb78cde88b52abed1a5a5abbc9919998.1697632761.git.baolin.wang@linux.alibaba.com> <1F80D8DA-8BB5-4C7E-BC2F-030BF52931F7@nvidia.com> <87il73uos1.fsf@yhuang6-desk2.ccr.corp.intel.com> <2ad721be-b81e-d279-0055-f995a8cfe180@linux.alibaba.com> <27f40fc2-806a-52a9-3697-4ed9cd7081d4@intel.com> From: Baolin Wang In-Reply-To: <27f40fc2-806a-52a9-3697-4ed9cd7081d4@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/19/2023 4:22 PM, Yin Fengwei wrote: > Hi Baolin, > > On 10/19/23 15:25, Baolin Wang wrote: >> >> >> On 10/19/2023 2:09 PM, Huang, Ying wrote: >>> Zi Yan writes: >>> >>>> On 18 Oct 2023, at 9:04, Baolin Wang wrote: >>>> >>>>> When doing compaction, I found the lru_add_drain() is an obvious hotspot >>>>> when migrating pages. The distribution of this hotspot is as follows: >>>>>     - 18.75% compact_zone >>>>>        - 17.39% migrate_pages >>>>>           - 13.79% migrate_pages_batch >>>>>              - 11.66% migrate_folio_move >>>>>                 - 7.02% lru_add_drain >>>>>                    + 7.02% lru_add_drain_cpu >>>>>                 + 3.00% move_to_new_folio >>>>>                   1.23% rmap_walk >>>>>              + 1.92% migrate_folio_unmap >>>>>           + 3.20% migrate_pages_sync >>>>>        + 0.90% isolate_migratepages >>>>> >>>>> The lru_add_drain() was added by commit c3096e6782b7 ("mm/migrate: >>>>> __unmap_and_move() push good newpage to LRU") to drain the newpage to LRU >>>>> immediately, to help to build up the correct newpage->mlock_count in >>>>> remove_migration_ptes() for mlocked pages. However, if there are no mlocked >>>>> pages are migrating, then we can avoid this lru drain operation, especailly >>>>> for the heavy concurrent scenarios. >>>> >>>> lru_add_drain() is also used to drain pages out of folio_batch. Pages in folio_batch >>>> have an additional pin to prevent migration. See folio_get(folio); in folio_add_lru(). >>> >>> lru_add_drain() is called after the page reference count checking in >>> move_to_new_folio().  So, I don't this is an issue. >> >> Agree. The purpose of adding lru_add_drain() is to address the 'mlock_count' issue for mlocked pages. Please see commit c3096e6782b7 and related comments. Moreover I haven't seen an increase in the number of page migration failures due to page reference count checking after this patch. > > I agree with your. My understanding also is that the lru_add_drain() is only needed > for mlocked folio to correct mlock_count. Like to hear the confirmation from Huge. > > > But I have question: why do we need use page_was_mlocked instead of check > folio_test_mlocked(src)? Does page migration clear the mlock flag? Thanks. Yes, please see the call trace: try_to_migrate_one() ---> page_remove_rmap() ---> munlock_vma_folio().