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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=no 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 8ED15C2BA19 for ; Tue, 14 Apr 2020 08:19:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 35362206E9 for ; Tue, 14 Apr 2020 08:19:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 35362206E9 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 81EC58E0003; Tue, 14 Apr 2020 04:19:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A86C8E0001; Tue, 14 Apr 2020 04:19:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 670008E0003; Tue, 14 Apr 2020 04:19:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id 48FFE8E0001 for ; Tue, 14 Apr 2020 04:19:30 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 037DA180AD802 for ; Tue, 14 Apr 2020 08:19:29 +0000 (UTC) X-FDA: 76705761300.23.screw57_35b4bb19f655b X-HE-Tag: screw57_35b4bb19f655b X-Filterd-Recvd-Size: 4913 Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Apr 2020 08:19:28 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01355;MF=alex.shi@linux.alibaba.com;NM=1;PH=DS;RN=39;SR=0;TI=SMTPD_---0TvVqOrg_1586852360; Received: from IT-FVFX43SYHV2H.local(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0TvVqOrg_1586852360) by smtp.aliyun-inc.com(127.0.0.1); Tue, 14 Apr 2020 16:19:21 +0800 Subject: Re: [PATCH v8 03/10] mm/lru: replace pgdat lru_lock with lruvec lock To: Johannes Weiner Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, mgorman@techsingularity.net, tj@kernel.org, hughd@google.com, khlebnikov@yandex-team.ru, daniel.m.jordan@oracle.com, yang.shi@linux.alibaba.com, willy@infradead.org, shakeelb@google.com, Michal Hocko , Vladimir Davydov , Roman Gushchin , Chris Down , Thomas Gleixner , Vlastimil Babka , Qian Cai , Andrey Ryabinin , "Kirill A. Shutemov" , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Andrea Arcangeli , David Rientjes , "Aneesh Kumar K.V" , swkhack , "Potyra, Stefan" , Mike Rapoport , Stephen Rothwell , Colin Ian King , Jason Gunthorpe , Mauro Carvalho Chehab , Peng Fan , Nikolay Borisov , Ira Weiny , Kirill Tkhai , Yafang Shao , Wei Yang References: <1579143909-156105-1-git-send-email-alex.shi@linux.alibaba.com> <1579143909-156105-4-git-send-email-alex.shi@linux.alibaba.com> <20200116215222.GA64230@cmpxchg.org> <20200413180725.GA99267@cmpxchg.org> From: Alex Shi Message-ID: <42d5c2cb-3019-993f-eba7-33a1d69ef699@linux.alibaba.com> Date: Tue, 14 Apr 2020 16:19:01 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200413180725.GA99267@cmpxchg.org> Content-Type: text/plain; charset=gbk 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: =D4=DA 2020/4/14 =C9=CF=CE=E72:07, Johannes Weiner =D0=B4=B5=C0: > But isolation actually needs to lock out charging, or it would operate > on the wrong list: >=20 > isolation: commit_charge: > if (TestClearPageLRU(page)) > page->mem_cgroup =3D new > // page is still physically on > // the root_mem_cgroup's LRU. We're > // updating the wrong list: > memcg =3D page->mem_cgroup > spin_lock(memcg->lru_lock) > del_page_from_lru_list(page, memcg) > spin_unlock(memcg->lru_lock) >=20 > lrucare really is a mess. Even before this patch series, it makes > things tricky and subtle and error prone. >=20 > The only reason we're doing it is for when there is swapping without > swap tracking, in which case swap reahadead needs to put pages on the > LRU but cannot charge them until we have a faulting vma later. >=20 > But it's not clear how practical such a configuration is. Both memory > and swap are shared resources, and isolation isn't really effective > when you restrict access to memory but then let workloads swap freely. >=20 > Plus, the overhead of tracking is tiny - 512k per G of swap (0.04%). >=20 > Maybe we should just delete MEMCG_SWAP and unconditionally track swap > entry ownership when the memory controller is enabled. I don't see a > good reason not to, and it would simplify the entire swapin path, the > LRU locking, and the page->mem_cgroup stabilization rules. Hi Johannes, I think what you mean here is to keep swap_cgroup id even it was swaped, then we read back the page from swap disk, we don't need to charge it. So all other memcg charge are just happens on non lru list, thus we have no isolation required in above awkward scenario. That sounds a good idea. so, split_huge_page and mem_cgroup_migrate shoul= d be safe, tasks cgroup migration may needs extra from_vec->lru_lock. Is th= at right? That's a good idea. I'm glad to have a try... BTW, As to the memcg swapped page mixed in swap disk timely. Maybe we could tr= y Tim Chen's swap_slot for memcg. What's your idea? Thanks Alex