From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Shi Subject: Re: [PATCH v16 00/22] per memcg lru_lock Date: Mon, 20 Jul 2020 15:30:14 +0800 Message-ID: <04a2ad99-5d88-a300-6430-7a8da0946f04@linux.alibaba.com> References: <1594429136-20002-1-git-send-email-alex.shi@linux.alibaba.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <1594429136-20002-1-git-send-email-alex.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="utf-8" To: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, mgorman-3eNAlZScCAx27rWaFMvyedHuzzzSOjJt@public.gmane.org, tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org, daniel.m.jordan-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, yang.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org, willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org, lkp-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, iamjoonsoo.kim-Hm3cg6mZ9cc@public.gmane.org, richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org I am preparing/testing the patch v17 according comments from Hugh Dickins and Alexander Duyck. Many thanks for line by line review and patient suggestion! Please drop me any more comments or concern of any patches! Thanks a lot! Alex 在 2020/7/11 上午8:58, Alex Shi 写道: > The new version which bases on v5.8-rc4. Add 2 more patchs: > 'mm/thp: remove code path which never got into' > 'mm/thp: add tail pages into lru anyway in split_huge_page()' > and modified 'mm/mlock: reorder isolation sequence during munlock' > > Current lru_lock is one for each of node, pgdat->lru_lock, that guard for > lru lists, but now we had moved the lru lists into memcg for long time. Still > using per node lru_lock is clearly unscalable, pages on each of memcgs have > to compete each others for a whole lru_lock. This patchset try to use per > lruvec/memcg lru_lock to repleace per node lru lock to guard lru lists, make > it scalable for memcgs and get performance gain. > > Currently lru_lock still guards both lru list and page's lru bit, that's ok. > but if we want to use specific lruvec lock on the page, we need to 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 both actions: TestClearPageLRU and hold the > lru_lock. > > The typical usage of this is isolate_migratepages_block() in compaction.c > we have to take lru bit before lru lock, that serialized the page isolation > in memcg page charge/migration which will change page's lruvec and new > lru_lock in it. > > The above solution suggested by Johannes Weiner, and based on his new memcg > charge path, then have this patchset. (Hugh Dickins tested and contributed much > code from compaction fix to general code polish, thanks a lot!). > > The patchset includes 3 parts: > 1, some code cleanup and minimum optimization as a preparation. > 2, use TestCleanPageLRU as page isolation's precondition > 3, replace per node lru_lock with per memcg per node lru_lock > > Following Daniel Jordan's suggestion, I have run 208 'dd' with on 104 > containers on a 2s * 26cores * HT box with a modefied case: > https://git.kernel.org/pub/scm/linux/kernel/git/wfg/vm-scalability.git/tree/case-lru-file-readtwice > With this patchset, the readtwice performance increased about 80% > in concurrent containers. > > Thanks Hugh Dickins and Konstantin Khlebnikov, they both brought this > idea 8 years ago, and others who give comments as well: Daniel Jordan, > Mel Gorman, Shakeel Butt, Matthew Wilcox etc. > > Thanks for Testing support from Intel 0day and Rong Chen, Fengguang Wu, > and Yun Wang. Hugh Dickins also shared his kbuild-swap case. Thanks! 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=-10.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NICE_REPLY_A,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 B3083C433E0 for ; Mon, 20 Jul 2020 07:30:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8146220729 for ; Mon, 20 Jul 2020 07:30:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8146220729 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 0CD156B0003; Mon, 20 Jul 2020 03:30:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07CA66B0005; Mon, 20 Jul 2020 03:30:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E87C36B0006; Mon, 20 Jul 2020 03:30:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0065.hostedemail.com [216.40.44.65]) by kanga.kvack.org (Postfix) with ESMTP id CF3F66B0003 for ; Mon, 20 Jul 2020 03:30:25 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 417F81D40EF for ; Mon, 20 Jul 2020 07:30:25 +0000 (UTC) X-FDA: 77057631210.04.metal31_3e02cd026f23 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 1DB2380058E1 for ; Mon, 20 Jul 2020 07:30:25 +0000 (UTC) X-HE-Tag: metal31_3e02cd026f23 X-Filterd-Recvd-Size: 4560 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jul 2020 07:30:23 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R221e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01358;MF=alex.shi@linux.alibaba.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---0U3DnCGw_1595230215; Received: from IT-FVFX43SYHV2H.local(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0U3DnCGw_1595230215) by smtp.aliyun-inc.com(127.0.0.1); Mon, 20 Jul 2020 15:30:16 +0800 Subject: Re: [PATCH v16 00/22] per memcg lru_lock From: Alex Shi To: 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, hannes@cmpxchg.org, lkp@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, shakeelb@google.com, iamjoonsoo.kim@lge.com, richard.weiyang@gmail.com, kirill@shutemov.name References: <1594429136-20002-1-git-send-email-alex.shi@linux.alibaba.com> Message-ID: <04a2ad99-5d88-a300-6430-7a8da0946f04@linux.alibaba.com> Date: Mon, 20 Jul 2020 15:30:14 +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: <1594429136-20002-1-git-send-email-alex.shi@linux.alibaba.com> Content-Type: text/plain; charset=utf-8 X-Rspamd-Queue-Id: 1DB2380058E1 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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: I am preparing/testing the patch v17 according comments from Hugh Dickins and Alexander Duyck.=20 Many thanks for line by line review and patient suggestion! Please drop me any more comments or concern of any patches! Thanks a lot! Alex =E5=9C=A8 2020/7/11 =E4=B8=8A=E5=8D=888:58, Alex Shi =E5=86=99=E9=81=93: > The new version which bases on v5.8-rc4. Add 2 more patchs: > 'mm/thp: remove code path which never got into' > 'mm/thp: add tail pages into lru anyway in split_huge_page()' > and modified 'mm/mlock: reorder isolation sequence during munlock' >=20 > Current lru_lock is one for each of node, pgdat->lru_lock, that guard f= or > lru lists, but now we had moved the lru lists into memcg for long time.= Still > using per node lru_lock is clearly unscalable, pages on each of memcgs = have > to compete each others for a whole lru_lock. This patchset try to use p= er > lruvec/memcg lru_lock to repleace per node lru lock to guard lru lists,= make > it scalable for memcgs and get performance gain. >=20 > Currently lru_lock still guards both lru list and page's lru bit, that'= s ok. > but if we want to use specific lruvec lock on the page, we need to pin = down > the page's lruvec/memcg during locking. Just taking lruvec lock first m= ay be > undermined by the page's memcg charge/migration. To fix this problem, w= e could > take out the page's lru bit clear and use it as pin down action to bloc= k the > memcg changes. That's the reason for new atomic func TestClearPageLRU. > So now isolating a page need both actions: TestClearPageLRU and hold th= e > lru_lock. >=20 > The typical usage of this is isolate_migratepages_block() in compaction= .c > we have to take lru bit before lru lock, that serialized the page isola= tion > in memcg page charge/migration which will change page's lruvec and new=20 > lru_lock in it. >=20 > The above solution suggested by Johannes Weiner, and based on his new m= emcg=20 > charge path, then have this patchset. (Hugh Dickins tested and contribu= ted much > code from compaction fix to general code polish, thanks a lot!). >=20 > The patchset includes 3 parts: > 1, some code cleanup and minimum optimization as a preparation. > 2, use TestCleanPageLRU as page isolation's precondition > 3, replace per node lru_lock with per memcg per node lru_lock >=20 > Following Daniel Jordan's suggestion, I have run 208 'dd' with on 104 > containers on a 2s * 26cores * HT box with a modefied case: > https://git.kernel.org/pub/scm/linux/kernel/git/wfg/vm-scalability.git/= tree/case-lru-file-readtwice > With this patchset, the readtwice performance increased about 80% > in concurrent containers. >=20 > Thanks Hugh Dickins and Konstantin Khlebnikov, they both brought this > idea 8 years ago, and others who give comments as well: Daniel Jordan,=20 > Mel Gorman, Shakeel Butt, Matthew Wilcox etc. >=20 > Thanks for Testing support from Intel 0day and Rong Chen, Fengguang Wu, > and Yun Wang. Hugh Dickins also shared his kbuild-swap case. Thanks!