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.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 CF18FC3F2D2 for ; Thu, 5 Mar 2020 18:05:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 74B952072D for ; Thu, 5 Mar 2020 18:05:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="H9m+cgWK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 74B952072D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D40A76B0005; Thu, 5 Mar 2020 13:05:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CF20F6B0006; Thu, 5 Mar 2020 13:05:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB99F6B0007; Thu, 5 Mar 2020 13:05:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id A0A726B0005 for ; Thu, 5 Mar 2020 13:05:18 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 730A72C8A for ; Thu, 5 Mar 2020 18:05:18 +0000 (UTC) X-FDA: 76562085516.18.burn96_4b641b105671c X-HE-Tag: burn96_4b641b105671c X-Filterd-Recvd-Size: 5810 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Thu, 5 Mar 2020 18:05:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583431517; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7P/Tm40PawYyBgzyeFKJHRkZBMi0AQCbs7jtSQN6B54=; b=H9m+cgWK0hL6nrxIPgXEJPVvSYxK+z7XXclnCKHxlsr4xI4oBT3F/p8fb5cgUgPm0A11lz xn1y8zHQ1BbE2hCst0R+q1ZJRth/fJg0u+nI8i0PS3r++j9DiJXdbVBlMslYxlk206Vb1o WEnItcbdeAF3WgX1zEqzqz4cpz1dtwg= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-194-FMghd9B6NuGmqyTFkhncKw-1; Thu, 05 Mar 2020 13:05:15 -0500 X-MC-Unique: FMghd9B6NuGmqyTFkhncKw-1 Received: by mail-qv1-f72.google.com with SMTP id g11so3540961qvl.3 for ; Thu, 05 Mar 2020 10:05:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=7P/Tm40PawYyBgzyeFKJHRkZBMi0AQCbs7jtSQN6B54=; b=HSkIdJ15nb1IabIzR/5muhgVv3ut7bodiA8JH3g9Xopeze4dKSGz2lBkOmcIqZAjQD 9PQabVrwazKp56/xiMHCdO27oQtpe0BcT233Mc5V9Y6E/2BJ69lYGWTQElRuqbxYojsP vmXNQna5GuC2wGdO4czaiOnO9mzNOyaiCdyA0nU76wAVSK4nIfkaYM3laWbf61pxVhZ7 6VUW9j0O61O8323C0ZI+ehI7FbuxThC2s/gSBQ8U8h21erH++z9hsmyVQfFyJ2Q8F24I 7LqGgvjp7fTew144we5zMQbVyjpcixSuCav3W2VYCu/wt51FVRm4qO93chYMfOOlnzZn uczg== X-Gm-Message-State: ANhLgQ2R5tgL6Cpk+ka1iFwPev+xRYV+wL2U9bVxgoHerLeM6/SYEulw fKWNnt6QVd01ThDSxRJ3a+QenwdHEv8Mu+calhykXqhVuDdYt+uofi1oVCOS3nBhqSWNu4fRKo0 KiNKGOegENBY= X-Received: by 2002:a05:620a:8cc:: with SMTP id z12mr3736315qkz.328.1583431515047; Thu, 05 Mar 2020 10:05:15 -0800 (PST) X-Google-Smtp-Source: ADFU+vvhh9UmPPCWc5F1SSWAviaFTnwLX2OpuYlL5EgBODDLUbENH7vHCB+Tv7yFNO5EASqL/xyqtA== X-Received: by 2002:a05:620a:8cc:: with SMTP id z12mr3736296qkz.328.1583431514775; Thu, 05 Mar 2020 10:05:14 -0800 (PST) Received: from desoxy ([2600:380:8e6a:dd9a:249c:973c:314e:6acf]) by smtp.gmail.com with ESMTPSA id t29sm16959083qtt.20.2020.03.05.10.05.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2020 10:05:13 -0800 (PST) Message-ID: <7766fa1d3cd97499d3fe7f922c8c788b6a7a6dfb.camel@redhat.com> Subject: Re: [PATCH] mm/vmscan: Prioritize anonymous executable pages like we do file-backed From: Adam Jackson To: Michal Hocko Cc: linux-mm@kvack.org Date: Thu, 05 Mar 2020 13:05:11 -0500 In-Reply-To: <20200305151743.GB16139@dhcp22.suse.cz> References: <20200304203235.3623103-1-ajax@redhat.com> <20200305151743.GB16139@dhcp22.suse.cz> User-Agent: Evolution 3.34.0 (3.34.0-1.fc31) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 2020-03-05 at 16:17 +0100, Michal Hocko wrote: > On Wed 04-03-20 15:32:35, 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. > > Are you seeing an actual improvement from this change? IIRC the primary > motivation to make this heuristic page cache oriented is that it was > quite easy to evict file backed memory by streaming IO. This shouldn't > really be a major problem for the anonymous memory in most cases. A > heavy swapin/out workload is likely to suffer from not having data > available more than having the code evicted. But I might be wrong here > and getting some numbers would be really interesting. They would be! I confess I don't have any, I'll see if I can gather some for you. The problem case for this patch is maybe as much about streaming I/O as it's about just giant wads of dirty data. Given enough pressure, eventually this loop will prefer to evict jitted code before precompiled. I find that to be a difficult preference to justify. If anything maybe you should evict the file-backed code first because you can discard it instead of writing it out (assuming your swap and executables are on comparably fast disk, etc). That's my theory anyway. It's entirely possible I don't understand the larger environment for this code, and like I say I don't have hard data yet. For all I know big data-center-y java jobs might actually want the existing behavior. But it seemed curious enough to warrant at least sending the patch for feedback. - ajax