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 X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 093D7C433E2 for ; Sun, 19 Jul 2020 11:24:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ACD4A20724 for ; Sun, 19 Jul 2020 11:24:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ACD4A20724 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 10A0A8D0001; Sun, 19 Jul 2020 07:24:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0BA1F6B0005; Sun, 19 Jul 2020 07:24:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EEBAC8D0001; Sun, 19 Jul 2020 07:24:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id D94056B0003 for ; Sun, 19 Jul 2020 07:24:21 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7AADA18374973 for ; Sun, 19 Jul 2020 11:24:21 +0000 (UTC) X-FDA: 77054591922.05.crack12_4c07b0f26f1b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 4B7871836F64C for ; Sun, 19 Jul 2020 11:24:21 +0000 (UTC) X-HE-Tag: crack12_4c07b0f26f1b X-Filterd-Recvd-Size: 5938 Received: from out30-45.freemail.mail.aliyun.com (out30-45.freemail.mail.aliyun.com [115.124.30.45]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Sun, 19 Jul 2020 11:24:19 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R811e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04407;MF=alex.shi@linux.alibaba.com;NM=1;PH=DS;RN=20;SR=0;TI=SMTPD_---0U38ILvo_1595157849; Received: from IT-FVFX43SYHV2H.local(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0U38ILvo_1595157849) by smtp.aliyun-inc.com(127.0.0.1); Sun, 19 Jul 2020 19:24:09 +0800 Subject: Re: [PATCH v16 13/22] mm/lru: introduce TestClearPageLRU From: Alex Shi To: Alexander Duyck Cc: Andrew Morton , Mel Gorman , Tejun Heo , Hugh Dickins , Konstantin Khlebnikov , Daniel Jordan , Yang Shi , Matthew Wilcox , Johannes Weiner , kbuild test robot , linux-mm , LKML , cgroups@vger.kernel.org, Shakeel Butt , Joonsoo Kim , Wei Yang , "Kirill A. Shutemov" , Michal Hocko , Vladimir Davydov References: <1594429136-20002-1-git-send-email-alex.shi@linux.alibaba.com> <1594429136-20002-14-git-send-email-alex.shi@linux.alibaba.com> <072b39ac-b95a-94f1-67a2-3293d4550ff8@linux.alibaba.com> <530c222e-dfd4-f78e-e9d4-315fad6f816a@linux.alibaba.com> Message-ID: Date: Sun, 19 Jul 2020 19:24:06 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <530c222e-dfd4-f78e-e9d4-315fad6f816a@linux.alibaba.com> Content-Type: text/plain; charset=utf-8 X-Rspamd-Queue-Id: 4B7871836F64C X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 Content-Transfer-Encoding: quoted-printable 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: =E5=9C=A8 2020/7/19 =E4=B8=8B=E5=8D=8812:45, Alex Shi =E5=86=99=E9=81=93: >>> >>>> It might make it more readable to pull in the later patch that >>>> modifies isolate_lru_pages that has it using TestClearPageLRU. >>> As to this change, It has to do in this patch, since any TestClearPag= eLRU may >>> cause lru bit miss in the lru list, so the precondication check has t= o >>> removed here. >> So I think some of my cognitive dissonance is from the fact that you >> really are doing two different things here. You aren't really >> implementing the full TestClearPageLRU until patch 15. So this patch >> is doing part of 2a and 2b, and then patch 15 is following up and >> completing the 2a cases. I still think it might make more sense to >> pull out the pieces related to 2b and move them into a patch before >> this with documentation explaining that there should be no competition >> for the LRU flag because the page has transitioned to a reference >> count of zero. Then take the remaining bits and combine them with >> patch 15 since the description for the two is pretty similar. >> As to the patch split suggest, actually, Hugh and I talked about a few we= eks=20 ago when he give me these changes. We both thought keep these changes in = this patch looks better at that time. If it make you confuse, don't know a changed commit log make it better? Thanks Alex mm/lru: introduce TestClearPageLRU Currently lru_lock still guards both lru list and page's lru bit, tha= t's ok. but if we want to use specific lruvec lock on the page, we need t= o pin down the page's lruvec/memcg during locking. Just taking lruvec lock first may be undermined by the page's memcg charge/migration. To fix this problem, we could take out the page's lru bit clear and use it as pin down action to block the memcg changes. That's the reason for new atomic func TestClearPageLRU. So now isolating a page need bo= th actions: TestClearPageLRU and hold the lru_lock. This patch combines PageLRU check and ClearPageLRU into a macro func TestClearPageLRU. This function will be used as page isolation precondition to prevent other isolations some where else. Then there are may non PageLRU page on lru list, need to remove BUG checking accordingly. There 2 rules for lru bit: 1, the lru bit still indicate if a page on lru list, just in some temporary moment(isolating), the page may have no lru bit whe= n it's on lru list. but the page still must be on lru list when the lru bit is set. 2, have to remove lru bit before delete it from lru list. Hugh Dickins pointed that when a page is in freeing path and no one i= s possible to take it, non atomic lru bit clearing is better, like in __page_cache_release and release_pages. ANd no need get_page() before lru bit clear in isolate_lru_page, since it '(1) Must be called with an elevated refcount on the page'. As Andrew Morton mentioned this change would dirty cacheline for page isn't on LRU. But the lost would be acceptable with Rong Chen report: https://lkml.org/lkml/2020/3/4/173 Suggested-by: Johannes Weiner Signed-off-by: Alex Shi Cc: Hugh Dickins Cc: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Andrew Morton Cc: linux-kernel@vger.kernel.org Cc: cgroups@vger.kernel.org Cc: linux-mm@kvack.org