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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 17A6CC10DCE for ; Tue, 24 Mar 2020 06:28:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CB2DE2073E for ; Tue, 24 Mar 2020 06:28:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="f9VAvmlq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CB2DE2073E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 72A236B00D5; Tue, 24 Mar 2020 02:28:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DA876B00D7; Tue, 24 Mar 2020 02:28:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EEDE6B00D8; Tue, 24 Mar 2020 02:28:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0204.hostedemail.com [216.40.44.204]) by kanga.kvack.org (Postfix) with ESMTP id 45CCF6B00D5 for ; Tue, 24 Mar 2020 02:28:48 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 85C9AC728C for ; Tue, 24 Mar 2020 06:28:48 +0000 (UTC) X-FDA: 76629277536.07.shade58_2fbfe367bb60c X-HE-Tag: shade58_2fbfe367bb60c X-Filterd-Recvd-Size: 5108 Received: from mail-qt1-f195.google.com (mail-qt1-f195.google.com [209.85.160.195]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Mar 2020 06:28:48 +0000 (UTC) Received: by mail-qt1-f195.google.com with SMTP id i3so10259420qtv.8 for ; Mon, 23 Mar 2020 23:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UeR+WctkiQFjyudT58ukpFLDVLpreIAvF+0Uils+20U=; b=f9VAvmlq/OnYPz8TdXl8tGTtShIl3d4rinP15u1VrlUSmUaaOVVs2YhocxdpOrf/8C QhLKXiAJSrwJfZuppp2XDyMR5W3u0jKrM6kyT0af3Y+2vH6eV2j5K5Fmp3mElRmHPcR5 XeIZbUzDOycVk1fumI+fnQ0Rvy1MML/808QzQdMZikscRt3F5nHJPhRcNmVUJAD7L/Ml ELw4DmQHl6EuSJ4ap4HFhlhO57nDlUFlkc7n+Kofy5Ju2sd50ijHeZgQpYfxBdHT3A2R NTJA/7XIKo3YyWK77imovp1xPv5POMJr4lQZYBDUmYoIqEHX10AZXcewU05fw7e5o9q6 IeBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UeR+WctkiQFjyudT58ukpFLDVLpreIAvF+0Uils+20U=; b=hdNams7u9IYpBYIWtmWEzn3E1vRM9KVXEZhRksCpFg0gYkYje8mxsJRvF8rTyDyart PvHbFSx9F/9x6ZKRcouY6gZrSf1FfkPXjlaQm5OdTCUlGNOoWZrU9gi+CjHmOpAhPgmC OnswXaAMedNoyLzyMPBPPAsEGhWY6V4/zQvGPfcQTxfSk95Os9JEr0WyzhGYjMOiU90N VmpVX43mwMFU0zyjnmXIQnjNqFnkPXU9zc4VRzAhh8a8pxJKj4j5rV1j7NaaaQIKhHZu zyhrrkL2PQ5ki2/PdypQDEEwo+thGKq5m2hx2oEQwLkKErPal/pVtJB1Yapwd5Y1thB2 TCKA== X-Gm-Message-State: ANhLgQ2nQnZ2K8ApyLNzTD+DsbPTS77ui0FJ5pWtHBcIH4f8TkbfmCzW bconHDZbCXHeGBZ/PFAeHwT5bu3+tUYMFmbEWt35zNtx X-Google-Smtp-Source: ADFU+vs0c/6r9rUWsVmVu8Uq/NXxjewHjvbCESmshY1cW5DQswDnY3jgZwOm8Wsg0dI+KC6zSYPSRMS0hGd4qZDgnmA= X-Received: by 2002:aed:34e6:: with SMTP id x93mr24599704qtd.194.1585031326961; Mon, 23 Mar 2020 23:28:46 -0700 (PDT) MIME-Version: 1.0 References: <1584942732-2184-1-git-send-email-iamjoonsoo.kim@lge.com> <1584942732-2184-9-git-send-email-iamjoonsoo.kim@lge.com> <20200323174257.GF204561@cmpxchg.org> In-Reply-To: <20200323174257.GF204561@cmpxchg.org> From: Joonsoo Kim Date: Tue, 24 Mar 2020 15:28:36 +0900 Message-ID: Subject: Re: [PATCH v4 8/8] mm/swap: count a new anonymous page as a reclaim_state's rotate To: Johannes Weiner Cc: Andrew Morton , Linux Memory Management List , LKML , Michal Hocko , Hugh Dickins , Minchan Kim , Vlastimil Babka , Mel Gorman , kernel-team@lge.com, Joonsoo Kim Content-Type: text/plain; charset="UTF-8" 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: 2020=EB=85=84 3=EC=9B=94 24=EC=9D=BC (=ED=99=94) =EC=98=A4=EC=A0=84 2:43, J= ohannes Weiner =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > On Mon, Mar 23, 2020 at 02:52:12PM +0900, js1304@gmail.com wrote: > > From: Joonsoo Kim > > > > reclaim_stat's rotate is used for controlling the ratio of scanning pag= e > > between file and anonymous LRU. All new anonymous pages are counted > > for rotate before the patch, protecting anonymous pages on active LRU, = and, > > it makes that reclaim on anonymous LRU is less happened than file LRU. > > > > Now, situation is changed. all new anonymous pages are not added > > to the active LRU so rotate would be far less than before. It will caus= e > > that reclaim on anonymous LRU happens more and it would result in bad > > effect on some system that is optimized for previous setting. > > > > Therefore, this patch counts a new anonymous page as a reclaim_state's > > rotate. Although it is non-logical to add this count to > > the reclaim_state's rotate in current algorithm, reducing the regressio= n > > would be more important. > > > > I found this regression on kernel-build test and it is roughly 2~5% > > performance degradation. With this workaround, performance is completel= y > > restored. > > > > v2: fix a bug that reuses the rotate value for previous page > > I agree with the rationale, but the magic bit in the page->lru list > pointers seems pretty ugly. Yes, pretty ugly. > I wrote a patch a few years ago that split lru_add_pvecs into an add > and a putback component. This was to avoid unintentional balancing > effects of LRU isolations, but I think you can benefit from that > cleanup here as well. Would you mind taking a look at it and maybe > take it up into your series? > > https://lore.kernel.org/patchwork/patch/685708/ Thanks for pointing that. I will remove the magic bit and imitate your patch to solve the problem of this patch. Thanks.