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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 65B61C0044D for ; Mon, 16 Mar 2020 16:12:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 09D782051A for ; Mon, 16 Mar 2020 16:12:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="w8j9Cvld" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 09D782051A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 813E46B0007; Mon, 16 Mar 2020 12:12:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C52A6B0008; Mon, 16 Mar 2020 12:12:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68B3F6B000A; Mon, 16 Mar 2020 12:12:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0082.hostedemail.com [216.40.44.82]) by kanga.kvack.org (Postfix) with ESMTP id 50EC56B0007 for ; Mon, 16 Mar 2020 12:12:13 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id ED888941A for ; Mon, 16 Mar 2020 16:12:12 +0000 (UTC) X-FDA: 76601717304.21.spade68_1339e8a8e5c37 X-HE-Tag: spade68_1339e8a8e5c37 X-Filterd-Recvd-Size: 7132 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Mon, 16 Mar 2020 16:12:11 +0000 (UTC) Received: by mail-qt1-f169.google.com with SMTP id f17so13362258qtq.6 for ; Mon, 16 Mar 2020 09:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=Dey7Nfe81uVrTNj3sIdJJjvqn+aY0k6NabLHjTXVQgc=; b=w8j9CvldLZ2D7h6Ij54OQbDHCt4dvW1qlF2jFOU6bKJC+FWYhlg4pTSX2slDSgpvaY v78RUSDf9i+oNhlrhP0t1jL20swq1QNObDXZgS27P0G87/LXhxi6DXwEkiLexmjT+qrz lFyhVr0W8yXnSMKFS4O/g1Fufe6olDpN5SGzmT3Nbgg3mG2iSNUSflfnduUKv1qDduuD Djsge/vuQ7qKZxohkayCmlUM209dzagcpISs2anbZ4Z5/juz+ipkV0+ORpBdJPNBTo6O 60Z6lguM1f39zHp3lQWFG2BTu4UPgpXXYVJeSD+N5dhyHDBIcK3iaDnSoRhiYb5frEOg FAKQ== 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:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=Dey7Nfe81uVrTNj3sIdJJjvqn+aY0k6NabLHjTXVQgc=; b=i8lZnnjmOkHVSa3QLf/Dcv3RjShnIxGB+OYd1J7Lj0kN6bqOqQXXaaJZBdpQcZmitb JrVMtjKtxe/g3DYhnNt7++JHCRxG45GHtdi+iU3oDD7OQBpMNfMHNRmNZRfBjUkkSYOe 82bK/1lzBLXYcfuXipGUQzDIT8Gh5FJkR8NmiewTKDo4lAAu4vpldtFTumvYoIRVlItU 0m8SOIUqZmBq5bfrfnLf9t55I6AERmmD/ZAP7GLPgE0U1+wD78KRPMMV2nT9AZHjcvvL u5XQ4oM2byaGbSshx9ZOZhdtxjDBC8hQEwnLJmfVYraoqw/iAtS85M5AZEVfG7HwZbvd Kswg== X-Gm-Message-State: ANhLgQ0nmp5/4OAhYykvOT26LCeccqFD8tc6cukrkbU+F3fSCOZ5ZCdP 4BsiLVJJuB45T0Zy+5PGADRIXg== X-Google-Smtp-Source: ADFU+vtkMxGQKCmWB2/JNmoCNAEOloHf3syOC+7yPP+yULjcDrHJba/ilgc3LIO7BVd33CSzKVEpXQ== X-Received: by 2002:aed:2284:: with SMTP id p4mr763287qtc.329.1584375130425; Mon, 16 Mar 2020 09:12:10 -0700 (PDT) Received: from localhost (70.44.39.90.res-cmts.bus.ptd.net. [70.44.39.90]) by smtp.gmail.com with ESMTPSA id u51sm105580qth.46.2020.03.16.09.12.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2020 09:12:09 -0700 (PDT) Date: Mon, 16 Mar 2020 12:12:08 -0400 From: Johannes Weiner To: Joonsoo Kim Cc: Andrew Morton , Linux Memory Management List , LKML , Michal Hocko , Hugh Dickins , Minchan Kim , Vlastimil Babka , Mel Gorman , kernel-team@lge.com, Joonsoo Kim Subject: Re: [PATCH v2 2/9] mm/vmscan: protect the workingset on anonymous LRU Message-ID: <20200316161208.GB67986@cmpxchg.org> References: <1582175513-22601-1-git-send-email-iamjoonsoo.kim@lge.com> <1582175513-22601-3-git-send-email-iamjoonsoo.kim@lge.com> <20200312151423.GH29835@cmpxchg.org> <20200313195510.GA67986@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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: On Mon, Mar 16, 2020 at 04:05:30PM +0900, Joonsoo Kim wrote: > 2020=EB=85=84 3=EC=9B=94 14=EC=9D=BC (=ED=86=A0) =EC=98=A4=EC=A0=84 4:5= 5, Johannes Weiner =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84= =B1: > > The problem with executables is that when they are referenced, they > > get a *lot* of references compared to data pages. Think about an > > instruction stream and how many of those instructions result in data > > references. So when you see an executable page that is being accessed= , > > it's likely being accessed at a high rate. They're much hotter, and > > that's why reference bits from VM_EXEC mappings carry more weight. >=20 > Sound reasonable. >=20 > But, now, I have another thought about it. I think that the root of the= reason > of this check is that there are two different reference tracking models > on file LRU. If we assume that all file pages are mapped ones, this spe= cial > check isn't needed. If executable pages are accessed more frequently th= an > others, reference can be found more for them at LRU cycle. No need for = this > special check. >=20 > However, file pages includes syscall-ed pages and mapped pages, and, > reference tracking models for mapped page has a disadvantage to > one for syscall-ed page. Several references for mapped page would be > considered as one at LRU cycle. I think that this check is to mitigate > this disadvantage, at least, for executable file mapped page. Hm, I don't quite understand this reasoning. Yes, there are two models for unmapped and mapped file pages. But both types of pages get activated with two or more references: for unmapped it's tracked through mark_page_accessed(), and for mapped it's the two LRU cycles with the referenced bit set (unmapped pages don't get that extra trip around the LRU with one reference). With that alone, mapped pages and unmapped pages should have equal chances, no? > > IMO this applies to executable file and anon equally. >=20 > anon LRU consist of all mapped pages, so, IMHO, there is no need for > special handling for executable pages on anon LRU. Although reference > is just checked at LRU cycle, it would correctly approximate reference > frequency. >=20 > Moreover, there is one comment in shrink_active_list() that explains on= e > reason about omission of this check for anon pages. >=20 > "Anon pages are not likely to be evicted by use-once streaming IO, plus= JVM > can create lots of anon VM_EXEC pages, so we ignore them here." > > Lastly, as I said before, at least, it is done separately with appropri= ate > investigation. You do have a point here, though. The VM_EXEC protection is a heuristic that I think was added for one specific case. Instead of adopting it straight-away for anon pages, it may be good to wait until a usecase materializes. If it never does, all the better - one less heuristic to carry around. > Now, I plan to make a next version applied all your comments except > VM_EXEC case. As I said above, fundamental difference between > file mapped page and anon mapped page is that file LRU where file mappe= d > pages are managed uses two reference tracking model but anon LRU uses > just one. File LRU needs some heuristic to adjust the difference of two= models, > but, anon LRU doesn't need at all. And, I think VM_EXEC check is for th= is case. >=20 > Please let me know your opinion about VM_EXEC case. I will start to rew= ork > if you agree with my thought. That sounds like a good plan. I'm looking forward to the next version! Johannes