Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp703672ybz; Wed, 15 Apr 2020 17:05:41 -0700 (PDT) X-Google-Smtp-Source: APiQypLasdmqQPJ19JRRzpiDXQnQrKgbKNVlGVOeiNmsv39vlNvAgclS+u7YqnVM4IhvMz4wBsY8 X-Received: by 2002:a05:6402:17c4:: with SMTP id s4mr19548382edy.348.1586995541748; Wed, 15 Apr 2020 17:05:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586995541; cv=none; d=google.com; s=arc-20160816; b=R2XSsLRSaAcVrnu/b5s6VhR7YW9CgHRhHvMtgjWtC5vaM9aa0fsWlMyreqOQ4IGYZW zP2mzS8+oLHUdPlyfWcfpgXcNWa+4aUg+WFYEi5UyV5lYJIHFxBf3WLKFRbSppj/85Ey JHXwDOTsXZtnlVkV0kXa73O/hW0TrbUgpaKBDXUxLeo3FrEd0jGo40MoRf2utKqvhMCP blkEtlvGfaUhjwhBxMLdhKi7nK0d4E/3CVuzUggIzDtYYDLT+zNRh6j5Sg7YFG1J644I qO1M6d8LE3PIJ4lmfaYmIZRuQU6+5M4a+qFJBHwouIav5tlxO83j+wYtx71T0mTnye3W 4oSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=JSaNv11nN/zNiqiZvV+2yJm1mBn9/MqDC2AJN1QIs4M=; b=tOT806rGp/ghp/21bIv73XER5aiESdAshUiq1IutpoPC4zvDc9LqdSiabQrFlN0IG4 rAbUIY49yabRC6dR3/eYocUXY91UWao095mep0Uvmapc5bF+9n/Lyx7W6tLSDJwBRLfL eiH+EdKT+1pgv5AJbkzCfNGLStSrRJGzjUFnfuktAQVkzhxyCrUJ8LgJ/VUUcq5+bXPp CFSvmp5V3yJYhQxnwnIVYuTeODRkyNWzikCr/G5EABfjCBMxUUR3syfikj8Wox689QgE oyYd1wxIS2K9+2iSBUi4rjHRFWrx+OaAOQeSPkQX4sCOG/rScZw7Mk59lVw/EJ1AcZO1 Rh9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h1si10452365ejd.517.2020.04.15.17.05.18; Wed, 15 Apr 2020 17:05:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2633417AbgDONnJ (ORCPT + 99 others); Wed, 15 Apr 2020 09:43:09 -0400 Received: from out30-133.freemail.mail.aliyun.com ([115.124.30.133]:49077 "EHLO out30-133.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730647AbgDONnH (ORCPT ); Wed, 15 Apr 2020 09:43:07 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R151e4;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=38;SR=0;TI=SMTPD_---0TvcmpSS_1586958174; Received: from IT-FVFX43SYHV2H.lan(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0TvcmpSS_1586958174) by smtp.aliyun-inc.com(127.0.0.1); Wed, 15 Apr 2020 21:42:55 +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 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> <8e7bf170-2bb5-f862-c12b-809f7f7d96cb@linux.alibaba.com> <20200414163114.GA136578@cmpxchg.org> From: Alex Shi Message-ID: <54af0662-cbb4-88c7-7eae-f969684025dd@linux.alibaba.com> Date: Wed, 15 Apr 2020 21:42:26 +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: <20200414163114.GA136578@cmpxchg.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2020/4/15 上午12:31, Johannes Weiner 写道: > On Tue, Apr 14, 2020 at 12:52:30PM +0800, Alex Shi wrote: >> 在 2020/4/14 上午2:07, Johannes Weiner 写道: >>> Plus, the overhead of tracking is tiny - 512k per G of swap (0.04%). >>> >>> 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. >>> >> >> Sorry for not follow you up, did you mean just remove the MEMCG_SWAP configuration >> and keep the feature in default memcg? > > Yes. > >> That does can remove lrucare, but PageLRU lock scheme still fails since >> we can not isolate the page during commit_charge, is that right? > > No, without lrucare the scheme works. Charges usually do: > > page->mem_cgroup = new; > SetPageLRU(page); > > And so if you can TestClearPageLRU(), page->mem_cgroup is stable. > > lrucare charging is the exception: it changes page->mem_cgroup AFTER > PageLRU has already been set, and even when it CANNOT acquire the > PageLRU lock itself. It violates the rules. > > If we make MEMCG_SWAP mandatory, we always have cgroup records for > swapped out pages. That means we can charge all swapin pages > (incl. readahead pages) directly in __read_swap_cache_async(), before > setting PageLRU on the new pages. > > Then we can delete lrucare. > > And then TestClearPageLRU() guarantees page->mem_cgroup is stable. > Hi Johannes, Thanks a lot for point out! Charging in __read_swap_cache_async would ask for 3 layers function arguments pass, that would be a bit ugly. Compare to this, could we move out the lru_cache add after commit_charge, like ksm copied pages? That give a bit extra non lru list time, but the page just only be used only after add_anon_rmap setting. Could it cause troubles? I tried to track down the reason of lru_cache_add here, but no explanation till first git kernel commit. Thanks Alex