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=-17.9 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 13734C433E3 for ; Mon, 24 Aug 2020 20:24:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E36242078D for ; Mon, 24 Aug 2020 20:24:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MR7Bq/ZQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726532AbgHXUYk (ORCPT ); Mon, 24 Aug 2020 16:24:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725904AbgHXUYk (ORCPT ); Mon, 24 Aug 2020 16:24:40 -0400 Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC461C061574 for ; Mon, 24 Aug 2020 13:24:38 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id k4so9520365oik.2 for ; Mon, 24 Aug 2020 13:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=jZJmpxUuRgi9v+jqMkzrZxBWaBUdOYUK94hlHfWB0r0=; b=MR7Bq/ZQYkG+RC4+pV7gn6md1ynlBoEqj97iWI4NmkE5R4tB+vonwjD3hBXKNY5NXi s6RgBUQ6GmZB9oN4eO759+P2STSWXsvR2iTFwi5em6FO1uSp9K6BrqWiBz2kHenZzz1P Py+yCIIKP4LDK18RFOWS5hwNf9QS/atikITGHcNt+QLbnxvvnLbqWHGkYnXujCSOVLTs 81PlBJi5s6WGIJnJ2cHHmh6PUWyvIS66CnqqIjAVzz/+qHPYBCk5bMfIYwxbQwPJZTlO HeP6Hse7VzkhwJXSINHM5U3hSAJUo0uzysf4ar42eBFpZytIQnrqwxAFiM3GD2E23ZeY IOmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=jZJmpxUuRgi9v+jqMkzrZxBWaBUdOYUK94hlHfWB0r0=; b=lZSsnE1YflpkRoL/h/mr98/ap1b5C1Bu9L82qxQWcP+/q1VNDnJdgFiGcRYjSe+fk/ rcwrKIp+ygOP6dzDF3bB8y8I7I20s2rf10iSt6QL5MFQdFvWgXL8M6Y6fMOUuXjTZF33 jCThzrjV3ZvtyrNhRgKqis+bepWU7TaOaZtJ+SowTkpLy7atiTXE7JoPeiPGRd0ro49K EANS6/EpcwP6b7STze1DzNUfwtBI2Q1ozTD637qHMKLMbl37CI2w3XKMhYxsEqI30OXi mKfn8Q0koMQvGfslN92koLfJLjjnZwk8IRPLg8VmDJjwPoeUSfFAP4j8Sznh2/Whntj/ q/Vg== X-Gm-Message-State: AOAM5314BtThKrVamYWS6J0rb725O8TQ/NJ9x3Y1yww/QzxKPhl8Zsn/ zYQGiUGdO5STxKa2NTAmzOJPHg== X-Google-Smtp-Source: ABdhPJwTgYizqjG5+M4jDsuRlA7NwkFtJ6lTlVT81F3k+vnUeL/RKMp78IcmS5oQunUsuiR9Fo0rKQ== X-Received: by 2002:aca:670b:: with SMTP id z11mr707247oix.6.1598300677784; Mon, 24 Aug 2020 13:24:37 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id a15sm2130930oid.49.2020.08.24.13.24.33 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Mon, 24 Aug 2020 13:24:36 -0700 (PDT) Date: Mon, 24 Aug 2020 13:24:20 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Andrew Morton cc: Alex Shi , mgorman@techsingularity.net, tj@kernel.org, hughd@google.com, khlebnikov@yandex-team.ru, daniel.m.jordan@oracle.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, alexander.duyck@gmail.com, rong.a.chen@intel.com, mhocko@suse.com, vdavydov.dev@gmail.com, shy828301@gmail.com Subject: Re: [PATCH v18 00/32] per memcg lru_lock In-Reply-To: <20200824114204.cc796ca182db95809dd70a47@linux-foundation.org> Message-ID: References: <1598273705-69124-1-git-send-email-alex.shi@linux.alibaba.com> <20200824114204.cc796ca182db95809dd70a47@linux-foundation.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 24 Aug 2020, Andrew Morton wrote: > On Mon, 24 Aug 2020 20:54:33 +0800 Alex Shi wrote: > > > The new version which bases on v5.9-rc2. Well timed and well based, thank you Alex. Particulary helpful to me, to include those that already went into mmotm: it's a surer foundation to test on top of the -rc2 base. > > the first 6 patches was picked into > > linux-mm, and add patch 25-32 that do some further post optimization. > > 32 patches, version 18. That's quite heroic. I'm unsure whether I > should merge it up at this point - what do people think? I'd love for it to go into mmotm - but not today. Version 17 tested out well. I've only just started testing version 18, but I'm afraid there's been a number of "improvements" in between, which show up as warnings (lots of VM_WARN_ON_ONCE_PAGE(!memcg) - I think one or more of those are already in mmotm and under discussion on the list, but I haven't read through yet, and I may have caught more cases to examine; a per-cpu warning from munlock_vma_page(); something else flitted by at reboot time before I could read it). No crashes so far, but I haven't got very far with it yet. I'll report back later in the week. Andrew demurred on version 17 for lack of review. Alexander Duyck has been doing a lot on that front since then. I have intended to do so, but it's a mirage that moves away from me as I move towards it: I have some time in the coming weeks to get back to that, but it would help me if the series is held more static by being in mmotm - we may need fixes, but improvements are liable to get in the way of finalizing. I still find the reliance on TestClearPageLRU, rather than lru_lock, hard to wrap my head around: but for so long as it's working correctly, please take that as a problem with my head (and something we can certainly change later if necessary, by re-adding the use of lru_lock in certain places (or by fitting me with a new head)). > > > > > 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. > > That's rather a slight amount of performance testing for a huge > performance patchset! Indeed. And I see that clause about readtwice performance increased 80% going back eight months to v6: a lot of fundamental bugs have been fixed in it since then, so I do think it needs refreshing. It could be faster now: v16 or v17 fixed the last bug I knew of, which had been slowing down reclaim considerably. When I last timed my repetitive swapping loads (not loads anyone sensible would be running with), across only two memcgs, Alex's patchset was slightly faster than without: it really did make a difference. But I tend to think that for all patchsets, there exists at least one test that shows it faster, and another that shows it slower. > Is more detailed testing planned? Not by me, performance testing is not something I trust myself with, just get lost in the numbers: Alex, this is what we hoped for months ago, please make a more convincing case, I hope Daniel and others can make more suggestions. But my own evidence suggests it's good. Hugh 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=-17.9 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=ham 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 C4CF2C433E1 for ; Mon, 24 Aug 2020 20:24:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7B4B42078D for ; Mon, 24 Aug 2020 20:24:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MR7Bq/ZQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B4B42078D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 12EEA900003; Mon, 24 Aug 2020 16:24:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E0C18D0003; Mon, 24 Aug 2020 16:24:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F1031900003; Mon, 24 Aug 2020 16:24:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0149.hostedemail.com [216.40.44.149]) by kanga.kvack.org (Postfix) with ESMTP id D76F28D0003 for ; Mon, 24 Aug 2020 16:24:39 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8C683362A for ; Mon, 24 Aug 2020 20:24:39 +0000 (UTC) X-FDA: 77186590278.27.spy03_02085ad27056 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 5C7E03D663 for ; Mon, 24 Aug 2020 20:24:39 +0000 (UTC) X-HE-Tag: spy03_02085ad27056 X-Filterd-Recvd-Size: 6961 Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Mon, 24 Aug 2020 20:24:38 +0000 (UTC) Received: by mail-oi1-f193.google.com with SMTP id e6so9522944oii.4 for ; Mon, 24 Aug 2020 13:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=jZJmpxUuRgi9v+jqMkzrZxBWaBUdOYUK94hlHfWB0r0=; b=MR7Bq/ZQYkG+RC4+pV7gn6md1ynlBoEqj97iWI4NmkE5R4tB+vonwjD3hBXKNY5NXi s6RgBUQ6GmZB9oN4eO759+P2STSWXsvR2iTFwi5em6FO1uSp9K6BrqWiBz2kHenZzz1P Py+yCIIKP4LDK18RFOWS5hwNf9QS/atikITGHcNt+QLbnxvvnLbqWHGkYnXujCSOVLTs 81PlBJi5s6WGIJnJ2cHHmh6PUWyvIS66CnqqIjAVzz/+qHPYBCk5bMfIYwxbQwPJZTlO HeP6Hse7VzkhwJXSINHM5U3hSAJUo0uzysf4ar42eBFpZytIQnrqwxAFiM3GD2E23ZeY IOmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=jZJmpxUuRgi9v+jqMkzrZxBWaBUdOYUK94hlHfWB0r0=; b=dCf+7jqsX18h+IjzUXWGs5S5FPCIvXn06bIRCCxkU7JoK6o8+3tWPE6DN69oQMRBE4 enF91I5PeQjj/xZ5m53Y7btCmG9YhmylzzxzJTSpiPa0Imfovr6GoF1J7D8xI9jJ56Mp M0x2bdH0527Bp1UerHWfC+vXm+788IOyqOeDaQOLgwwtVmFhocxSlSXzhrO7GNPkZ59l yede2070lfaX7ASNu+a4Oz32v+f6aiBxICV0bGohPIF74kKv6x1Qce5gpqnZjv93l/Ox 7Sv52egZxou7l9HhJvHmOo/ZzuW40yrHa+m7mZAmDEMOLtWKd2y08JuSKmyINVRdaav2 wgfQ== X-Gm-Message-State: AOAM533PvOTGu/G4VxZn22m0qxgO2w9yOZf82nqE6PkoHPGW4ynAGHNq 6pQVBgZh/Sg4XDmC4snNZMQpog== X-Google-Smtp-Source: ABdhPJwTgYizqjG5+M4jDsuRlA7NwkFtJ6lTlVT81F3k+vnUeL/RKMp78IcmS5oQunUsuiR9Fo0rKQ== X-Received: by 2002:aca:670b:: with SMTP id z11mr707247oix.6.1598300677784; Mon, 24 Aug 2020 13:24:37 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id a15sm2130930oid.49.2020.08.24.13.24.33 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Mon, 24 Aug 2020 13:24:36 -0700 (PDT) Date: Mon, 24 Aug 2020 13:24:20 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Andrew Morton cc: Alex Shi , mgorman@techsingularity.net, tj@kernel.org, hughd@google.com, khlebnikov@yandex-team.ru, daniel.m.jordan@oracle.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, alexander.duyck@gmail.com, rong.a.chen@intel.com, mhocko@suse.com, vdavydov.dev@gmail.com, shy828301@gmail.com Subject: Re: [PATCH v18 00/32] per memcg lru_lock In-Reply-To: <20200824114204.cc796ca182db95809dd70a47@linux-foundation.org> Message-ID: References: <1598273705-69124-1-git-send-email-alex.shi@linux.alibaba.com> <20200824114204.cc796ca182db95809dd70a47@linux-foundation.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Rspamd-Queue-Id: 5C7E03D663 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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: On Mon, 24 Aug 2020, Andrew Morton wrote: > On Mon, 24 Aug 2020 20:54:33 +0800 Alex Shi wrote: > > > The new version which bases on v5.9-rc2. Well timed and well based, thank you Alex. Particulary helpful to me, to include those that already went into mmotm: it's a surer foundation to test on top of the -rc2 base. > > the first 6 patches was picked into > > linux-mm, and add patch 25-32 that do some further post optimization. > > 32 patches, version 18. That's quite heroic. I'm unsure whether I > should merge it up at this point - what do people think? I'd love for it to go into mmotm - but not today. Version 17 tested out well. I've only just started testing version 18, but I'm afraid there's been a number of "improvements" in between, which show up as warnings (lots of VM_WARN_ON_ONCE_PAGE(!memcg) - I think one or more of those are already in mmotm and under discussion on the list, but I haven't read through yet, and I may have caught more cases to examine; a per-cpu warning from munlock_vma_page(); something else flitted by at reboot time before I could read it). No crashes so far, but I haven't got very far with it yet. I'll report back later in the week. Andrew demurred on version 17 for lack of review. Alexander Duyck has been doing a lot on that front since then. I have intended to do so, but it's a mirage that moves away from me as I move towards it: I have some time in the coming weeks to get back to that, but it would help me if the series is held more static by being in mmotm - we may need fixes, but improvements are liable to get in the way of finalizing. I still find the reliance on TestClearPageLRU, rather than lru_lock, hard to wrap my head around: but for so long as it's working correctly, please take that as a problem with my head (and something we can certainly change later if necessary, by re-adding the use of lru_lock in certain places (or by fitting me with a new head)). > > > > > 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. > > That's rather a slight amount of performance testing for a huge > performance patchset! Indeed. And I see that clause about readtwice performance increased 80% going back eight months to v6: a lot of fundamental bugs have been fixed in it since then, so I do think it needs refreshing. It could be faster now: v16 or v17 fixed the last bug I knew of, which had been slowing down reclaim considerably. When I last timed my repetitive swapping loads (not loads anyone sensible would be running with), across only two memcgs, Alex's patchset was slightly faster than without: it really did make a difference. But I tend to think that for all patchsets, there exists at least one test that shows it faster, and another that shows it slower. > Is more detailed testing planned? Not by me, performance testing is not something I trust myself with, just get lost in the numbers: Alex, this is what we hoped for months ago, please make a more convincing case, I hope Daniel and others can make more suggestions. But my own evidence suggests it's good. Hugh From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugh Dickins Subject: Re: [PATCH v18 00/32] per memcg lru_lock Date: Mon, 24 Aug 2020 13:24:20 -0700 (PDT) Message-ID: References: <1598273705-69124-1-git-send-email-alex.shi@linux.alibaba.com> <20200824114204.cc796ca182db95809dd70a47@linux-foundation.org> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=jZJmpxUuRgi9v+jqMkzrZxBWaBUdOYUK94hlHfWB0r0=; b=MR7Bq/ZQYkG+RC4+pV7gn6md1ynlBoEqj97iWI4NmkE5R4tB+vonwjD3hBXKNY5NXi s6RgBUQ6GmZB9oN4eO759+P2STSWXsvR2iTFwi5em6FO1uSp9K6BrqWiBz2kHenZzz1P Py+yCIIKP4LDK18RFOWS5hwNf9QS/atikITGHcNt+QLbnxvvnLbqWHGkYnXujCSOVLTs 81PlBJi5s6WGIJnJ2cHHmh6PUWyvIS66CnqqIjAVzz/+qHPYBCk5bMfIYwxbQwPJZTlO HeP6Hse7VzkhwJXSINHM5U3hSAJUo0uzysf4ar42eBFpZytIQnrqwxAFiM3GD2E23ZeY IOmA== In-Reply-To: <20200824114204.cc796ca182db95809dd70a47-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: TEXT/PLAIN; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Andrew Morton Cc: Alex Shi , 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, 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, alexander.duyck-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, rong.a.chen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, mhocko-IBi9RG/b67k@public.gmane.org, vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, shy828301-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org On Mon, 24 Aug 2020, Andrew Morton wrote: > On Mon, 24 Aug 2020 20:54:33 +0800 Alex Shi wrote: > > > The new version which bases on v5.9-rc2. Well timed and well based, thank you Alex. Particulary helpful to me, to include those that already went into mmotm: it's a surer foundation to test on top of the -rc2 base. > > the first 6 patches was picked into > > linux-mm, and add patch 25-32 that do some further post optimization. > > 32 patches, version 18. That's quite heroic. I'm unsure whether I > should merge it up at this point - what do people think? I'd love for it to go into mmotm - but not today. Version 17 tested out well. I've only just started testing version 18, but I'm afraid there's been a number of "improvements" in between, which show up as warnings (lots of VM_WARN_ON_ONCE_PAGE(!memcg) - I think one or more of those are already in mmotm and under discussion on the list, but I haven't read through yet, and I may have caught more cases to examine; a per-cpu warning from munlock_vma_page(); something else flitted by at reboot time before I could read it). No crashes so far, but I haven't got very far with it yet. I'll report back later in the week. Andrew demurred on version 17 for lack of review. Alexander Duyck has been doing a lot on that front since then. I have intended to do so, but it's a mirage that moves away from me as I move towards it: I have some time in the coming weeks to get back to that, but it would help me if the series is held more static by being in mmotm - we may need fixes, but improvements are liable to get in the way of finalizing. I still find the reliance on TestClearPageLRU, rather than lru_lock, hard to wrap my head around: but for so long as it's working correctly, please take that as a problem with my head (and something we can certainly change later if necessary, by re-adding the use of lru_lock in certain places (or by fitting me with a new head)). > > > > > 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. > > That's rather a slight amount of performance testing for a huge > performance patchset! Indeed. And I see that clause about readtwice performance increased 80% going back eight months to v6: a lot of fundamental bugs have been fixed in it since then, so I do think it needs refreshing. It could be faster now: v16 or v17 fixed the last bug I knew of, which had been slowing down reclaim considerably. When I last timed my repetitive swapping loads (not loads anyone sensible would be running with), across only two memcgs, Alex's patchset was slightly faster than without: it really did make a difference. But I tend to think that for all patchsets, there exists at least one test that shows it faster, and another that shows it slower. > Is more detailed testing planned? Not by me, performance testing is not something I trust myself with, just get lost in the numbers: Alex, this is what we hoped for months ago, please make a more convincing case, I hope Daniel and others can make more suggestions. But my own evidence suggests it's good. Hugh