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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 F195EC10DCE for ; Fri, 6 Mar 2020 09:22:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 94F28207FD for ; Fri, 6 Mar 2020 09:22:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 94F28207FD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=techsingularity.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EDA2C6B0005; Fri, 6 Mar 2020 04:22:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E89D46B0006; Fri, 6 Mar 2020 04:22:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D78E06B0007; Fri, 6 Mar 2020 04:22:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0111.hostedemail.com [216.40.44.111]) by kanga.kvack.org (Postfix) with ESMTP id BDAA36B0005 for ; Fri, 6 Mar 2020 04:22:13 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 983CB181AEF00 for ; Fri, 6 Mar 2020 09:22:13 +0000 (UTC) X-FDA: 76564396146.28.glove96_4d8fb6e34fa1b X-HE-Tag: glove96_4d8fb6e34fa1b X-Filterd-Recvd-Size: 3980 Received: from outbound-smtp20.blacknight.com (outbound-smtp20.blacknight.com [46.22.139.247]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Fri, 6 Mar 2020 09:22:12 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp20.blacknight.com (Postfix) with ESMTPS id DE8A31C3B65 for ; Fri, 6 Mar 2020 09:22:10 +0000 (GMT) Received: (qmail 6155 invoked from network); 6 Mar 2020 09:22:10 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.18.57]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 6 Mar 2020 09:22:10 -0000 Date: Fri, 6 Mar 2020 09:22:08 +0000 From: Mel Gorman To: Adam Jackson Cc: Shakeel Butt , Vlastimil Babka , Linux MM , Johannes Weiner , Roman Gushchin , Joonsoo Kim , Michal Hocko Subject: Re: [PATCH] mm/vmscan: Prioritize anonymous executable pages like we do file-backed Message-ID: <20200306092208.GT3818@techsingularity.net> References: <20200304203235.3623103-1-ajax@redhat.com> <8b8420f9-12bc-b247-7727-f82038ffa6e7@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 05, 2020 at 05:58:59PM -0500, Adam Jackson wrote: > > 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. > > Enh. I would tend to think that code is way more precious than data in > terms of staying resident. If the working set detection works well > enough to come to that conclusion on its own without explictly knowing > about executable pages, that'd be awesome and I'd be entirely fine with > removing even more of this heuristic. > Given the increased use of JIT engines, the existence of working set detection and the fact it may also work for anonymous pages soon, I think it's worth at least *trying* to remove the heuristic in case it stays around for years as magic code. Creating an automated test case for this would be relatively tricky. Could you put together a debugging patch that simply counts some events to put into the changelog? The events (which could be vmstat) would be o VM_EXEC pages encountered in reclaim o Number exec file-backed pages preserved o Number exec anon pages preserved o Number exec file-backed pages reclaimed o NUmber exec anon pages reclaimed And show the figures before and after in the changelog running Firefox with excessive IO in the background. It's a bit of legwork but it's to preserve in the changelog that this problem definitely happens and the patch has a positive impact. Some comment saying the cursor is not laggy with the patch applied would also be a plus. The debugging patch would not actually be merged. With the figures, if there ever is a bug report that bisects to this patch, it'll be known exactly what the impact and motivation was. That will at least make people pause and think before blindly reverting it. I'm guessing the impact is that the ratio of reclaimed/preserved for anon pages is currently skewed and after the patch it's more in line with the ratio for file-backed. It's a tough prediction as the size of the file vs anon LRUs at the time of reclaim matter as well as the ordering of pages in the LRU. -- Mel Gorman SUSE Labs