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=-14.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, 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 60582C3F2D1 for ; Thu, 5 Mar 2020 20:41:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 201D42072D for ; Thu, 5 Mar 2020 20:41:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="u7dUMYV3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 201D42072D 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 C30FA6B0005; Thu, 5 Mar 2020 15:41:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BBBB46B0006; Thu, 5 Mar 2020 15:41:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A83326B0007; Thu, 5 Mar 2020 15:41:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0155.hostedemail.com [216.40.44.155]) by kanga.kvack.org (Postfix) with ESMTP id 8DED26B0005 for ; Thu, 5 Mar 2020 15:41:26 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 524A32476 for ; Thu, 5 Mar 2020 20:41:26 +0000 (UTC) X-FDA: 76562478972.05.edge80_80f2643d2541c X-HE-Tag: edge80_80f2643d2541c X-Filterd-Recvd-Size: 5903 Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Thu, 5 Mar 2020 20:41:25 +0000 (UTC) Received: by mail-ot1-f67.google.com with SMTP id i14so237331otp.5 for ; Thu, 05 Mar 2020 12:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tb2lsowheEEm6glelobPDNuAVQ+yaba6DKFL8GGGmFY=; b=u7dUMYV3O2ERMscpzqFdevmfwA5NIRg3SKymNW+M77TShnLx0xcoIFR8Qzf1RsYAv7 Pc04b8iWRs1PbtLidxDGEUSPV9Ogo+RlM54vl8roYSmCbYcKFGgflIGT4B374GzlUcOK uCFwirNd0C4aiCYDdjsD57dSXjymRBBnRaEl9ifZiUmfmTul/w59cmh32y3ftf1Vzole gabu3sSxDssK9pCqq4m9D5qDwAbg96BaCYlcX8MHg3aJ0jLc8zidxwYrxvQ92CqFktHw X5Zx4yJ5e4vX03xYa1V6QumplIPXay5Qv3pdS9aeE065Lzg2aqNkG2ihvh93Zp0JSFb3 Y9SQ== 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; bh=tb2lsowheEEm6glelobPDNuAVQ+yaba6DKFL8GGGmFY=; b=b3/JaPcsR/PZ8OazGWOM7YkvaRgePQrYU8aHjJDSeSKEunuIn2PcsbQ18rH/AFyEPS EuQm/6d1RQW872cTHOMwcDo49dSjRuWklrGvknizLMamnXuGcGddGkK6wJTCwlhUMz5s fWvP852/kCgXGazAA+qKEszCxzZGhS67rudJlRCIs16aXaMyvA0TeGRKis+nSTCh0QfP AXMgq2yGUORF8ZdSh2pBYn8u6O/mKNVNA/EP/AdfOPv43VfKa/lZqfjbdKIzNoAWXFVM aCxrTGXd3Em7yDguhF30uL4U2aEDJT0UTzbWvDpNcAACkuM88tcKHJOadHOwZyIRBvzn vNog== X-Gm-Message-State: ANhLgQ17PqduAEYW15+POXx3XIxowoyoMSMR2UjoSJZVnGVZUvXchKBq YZYGP08uAJW+Lnj5cpwpBEFl79RUKLbpZn2GZd6VwuTF X-Google-Smtp-Source: ADFU+vv8e8wRBGxDefPER+tVey4T77ol3JygIvk+4EX/FlKNseSdovIj8237blVcfNyAXT8hX2TW0rrbefoO+g2MDMs= X-Received: by 2002:a9d:6:: with SMTP id 6mr254394ota.191.1583440884844; Thu, 05 Mar 2020 12:41:24 -0800 (PST) MIME-Version: 1.0 References: <20200304203235.3623103-1-ajax@redhat.com> <8b8420f9-12bc-b247-7727-f82038ffa6e7@suse.cz> In-Reply-To: <8b8420f9-12bc-b247-7727-f82038ffa6e7@suse.cz> From: Shakeel Butt Date: Thu, 5 Mar 2020 12:41:14 -0800 Message-ID: Subject: Re: [PATCH] mm/vmscan: Prioritize anonymous executable pages like we do file-backed To: Vlastimil Babka Cc: Adam Jackson , Linux MM , Johannes Weiner , Roman Gushchin , Joonsoo Kim , Michal Hocko , Mel Gorman Content-Type: text/plain; charset="UTF-8" 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 Thu, Mar 5, 2020 at 4:47 AM Vlastimil Babka wrote: > > + CC folks who focus on reclaim > > On 3/4/20 9:32 PM, Adam Jackson wrote: > > The page reclamation scanner tries to keep executable pages resident, > > since taking a hard page fault to satisfy an icache miss is really not > > great for interactivity. Anonymous executable pages tend to contain > > code that has been just-in-time compiled for performance reasons. By > > requiring that executable pages be file-backed, we're putting possibly > > the most performance-sensitive code at higher risk of eviction, which > > seems backwards. > > > > On an amd64 machine running Fedora 31, the firefox I happen to have > > running requires about 89M of file-backed text and 12M of anonymous text > > for 30 open tabs. The next largest process in terms of anonymous text is > > gnome-shell, with 1M anonymous and 57M file-backed. No other process had > > significant anonymous text, most had none. Penalizing those 13M > > specifically when under memory pressure seems like an easy hazard to > > avoid. Have you actually seen this issue (i.e. JIT code reclaimed and thrashing) happening for real workloads? > > > > Signed-off-by: Adam Jackson > > --- > > mm/vmscan.c | 11 ++++------- > > 1 file changed, 4 insertions(+), 7 deletions(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index ee4eecc7e1c2..9bfbc30d61d8 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -2095,15 +2095,12 @@ static void shrink_active_list(unsigned long nr_to_scan, > > &vm_flags)) { > > nr_rotated += hpage_nr_pages(page); > > /* > > - * Identify referenced, file-backed active pages and > > - * give them one more trip around the active list. So > > + * Identify referenced, executable active pages and > > + * give them one more trip around the active list, so > > * that executable code get better chances to stay in > > - * memory under moderate memory pressure. 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. > > + * memory under moderate memory pressure. > > */ > > - if ((vm_flags & VM_EXEC) && page_is_file_cache(page)) { Originally this heuristic was added to protect executable file pages from the streaming workloads. Now we have workingset detection for file pages and there is ongoing work for adding that support for anon pages, I am wondering if this specific heuristic is still helpful. > > + if ((vm_flags & VM_EXEC)) { > > list_add(&page->lru, &l_active); > > continue; > > } > > >