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 23EE7C10F29 for ; Tue, 17 Mar 2020 04:52:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B8B9520658 for ; Tue, 17 Mar 2020 04:52:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RzRs3ha+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B8B9520658 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 4F0286B0005; Tue, 17 Mar 2020 00:52:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 49FED6B0006; Tue, 17 Mar 2020 00:52:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B5C16B0007; Tue, 17 Mar 2020 00:52:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0151.hostedemail.com [216.40.44.151]) by kanga.kvack.org (Postfix) with ESMTP id 24EB16B0005 for ; Tue, 17 Mar 2020 00:52:53 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id BE54D181AEF10 for ; Tue, 17 Mar 2020 04:52:52 +0000 (UTC) X-FDA: 76603634184.19.run01_70619cec9a14f X-HE-Tag: run01_70619cec9a14f X-Filterd-Recvd-Size: 6364 Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Tue, 17 Mar 2020 04:52:52 +0000 (UTC) Received: by mail-qt1-f193.google.com with SMTP id e20so16411673qto.5 for ; Mon, 16 Mar 2020 21:52:52 -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=HmNBZ2Fb6XAr6Ve5H1ieEf9RVZQcVNun5fBa1AuybTA=; b=RzRs3ha+V9ZJfk/lfquDxIObbYW7Ye830mzWa4TgY+JG0vg/QVno6YT0tVj7Ny2ciw yTV3CpcXfx0yBGgUjhZm4hsg6xVS41DLPvKsRhIquBtlxDAO0zjcOZMtBa7fqrbxiuN0 6Wl3ZtcO/OGJXTQOorrIkGm1OQdtSIEF4i4LlBvS5AGMVK9aLwZ/ouNh/dfzOn4CMknk fPXqePjtL8nJSfYs/vGDZRA1g5ROivtPrQ9vOtX/pGvSUKOL3Hp/Nn3pEGzzRMmxFbRL BRFnolx0GL6zW6/sLP5fMkjdkO7K8fFYxS3kfGdLvhUPyGTOijCPMRPkGDnPxz4HPfzd OcfQ== 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=HmNBZ2Fb6XAr6Ve5H1ieEf9RVZQcVNun5fBa1AuybTA=; b=iuHb1eb2DxDcEWTAkozC+czgnLD/O/IJ3mFxVMkVUB+hOdidOnG7AMPbh7woe3qHm7 cGu6KnU40BcolYZBtbRHXLyfw46PpH91HRR2yP6K/egKhmV41Nx6MzOBanEk6JC6NYtD TdYEj93191WJJJ7VL+FM8WQD6MwkkQ4TFrR3dCnC7abADOKY3BV6XAFcPIGqbXdfIWHA fh+0OrC2qeks9Tt/unfNDzquvi/Zd5GIZRQEB7ptTrsdV1TSYp4B63YVEqq1ic0hg7pt zZTcIVehdXx4mOhh/gTR8RCGFFndCW0sfTgA5OYY2RlHlOM98W/vQhrw4TC/baFFGeQJ Stfg== X-Gm-Message-State: ANhLgQ1vTHYikYNHjoUNMZ7TpoXInsfWs7x7MMTZvTatzri7+4Xw5kfZ fqRd3KajewhmcQ36eMxpG2mban0QnOOrhFtf+uo= X-Google-Smtp-Source: ADFU+vvpXxTgkHktukI3njVQwYIA+0aosdP4+TCG0/z1yf3lf29Xcigey0ElHXy5Kyj4rR2X1a84WG94Y4FH9A0CQus= X-Received: by 2002:aed:3346:: with SMTP id u64mr3395904qtd.333.1584420771409; Mon, 16 Mar 2020 21:52:51 -0700 (PDT) MIME-Version: 1.0 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> <20200316161208.GB67986@cmpxchg.org> In-Reply-To: <20200316161208.GB67986@cmpxchg.org> From: Joonsoo Kim Date: Tue, 17 Mar 2020 13:52:40 +0900 Message-ID: Subject: Re: [PATCH v2 2/9] mm/vmscan: protect the workingset on anonymous LRU 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 17=EC=9D=BC (=ED=99=94) =EC=98=A4=EC=A0=84 1:12, J= ohannes Weiner =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > 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. > > > > Sound reasonable. > > > > 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. > > > > 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? > Think about following example. Assume that the size of inactive list for file page is 100. 1. start the new page, A, and access to A happens 2. 50 inactive pages are reclaimed due to 50 new pages 3. second access to A happens 4. 50 inactive pages are reclaimed due to 50 new pages 5. 100 inactive pages are reclaimed due to 100 new pages If A is: unmapped page: the page is activated at #3 and lives after #5 mapped page: the page reference is checked at #4 and re-attached to the inactive list with PageReferenced() but is eventually reclaimed at #= 5 Even they are referenced by the same pattern, mapped page is reclaimed but unmapped isn't. This is, what I said before, the disadvantage of the mapped page than unmapped page. My guess is that to mitigate this disadvantage on mapped file page, VM_EXEC test is needed since VM_EXEC is the most important case for mapped file page. Thanks.