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=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 45092C433F7 for ; Wed, 15 Jul 2020 07:16:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E9D34206E9 for ; Wed, 15 Jul 2020 07:16:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="FKkUZ+ix" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E9D34206E9 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=amazon.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 62B578D0002; Wed, 15 Jul 2020 03:16:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DBD68D0001; Wed, 15 Jul 2020 03:16:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F2C58D0002; Wed, 15 Jul 2020 03:16:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id 3B9858D0001 for ; Wed, 15 Jul 2020 03:16:09 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id F2AF38248D52 for ; Wed, 15 Jul 2020 07:16:08 +0000 (UTC) X-FDA: 77039451216.17.loss53_550690826ef7 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id B3078180D018B for ; Wed, 15 Jul 2020 07:16:08 +0000 (UTC) X-HE-Tag: loss53_550690826ef7 X-Filterd-Recvd-Size: 3761 Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Wed, 15 Jul 2020 07:16:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1594797369; x=1626333369; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=HEw3+Ao/fqO9FvXA+Yo3+7G67lorJbwZfAa4e34wU6o=; b=FKkUZ+ixFASeTPY+2m6wAwM0YA2HW9sExpozMrc4IS3oO+zIytEYTxVC wpU5FRBncGRBUhiAI8GKnAVA4ZKnPyXxxBHbNKEho5pnIqDtedmHq559B E5uLm6OHdFZAla1czKEyzvjejFsE8NLosdLwzbR4QM3VcYxD3XKGgoGwR M=; IronPort-SDR: bESFgyDUpLZQJ2zcI5QT+WenhUMp3wdsKik+XScOdDK1qGtavlf4orhYokhiCxRzO+tLf+5GlT 5UWCX7q/0f8g== X-IronPort-AV: E=Sophos;i="5.75,354,1589241600"; d="scan'208";a="43418616" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2b-c7131dcf.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 15 Jul 2020 07:15:52 +0000 Received: from EX13MTAUEA002.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2b-c7131dcf.us-west-2.amazon.com (Postfix) with ESMTPS id 8C5C6A17C9; Wed, 15 Jul 2020 07:15:50 +0000 (UTC) Received: from EX13D31EUA004.ant.amazon.com (10.43.165.161) by EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Jul 2020 07:15:50 +0000 Received: from u886c93fd17d25d.ant.amazon.com (10.43.161.146) by EX13D31EUA004.ant.amazon.com (10.43.165.161) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Jul 2020 07:15:44 +0000 From: SeongJae Park To: David Rientjes CC: Andrew Morton , Yang Shi , Michal Hocko , Shakeel Butt , "Yang Shi" , Roman Gushchin , Greg Thelen , Johannes Weiner , Vladimir Davydov , , Subject: Re: Re: [patch] mm, memcg: provide a stat to describe reclaimable memory Date: Wed, 15 Jul 2020 09:15:22 +0200 Message-ID: <20200715071522.19663-1-sjpark@amazon.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: (raw) MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.43.161.146] X-ClientProxiedBy: EX13D14UWB003.ant.amazon.com (10.43.161.162) To EX13D31EUA004.ant.amazon.com (10.43.165.161) X-Rspamd-Queue-Id: B3078180D018B X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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: Hello David, On Wed, 15 Jul 2020 00:00:03 -0700 (PDT) David Rientjes wrote: > On Tue, 14 Jul 2020, David Rientjes wrote: > [...] > > An alternative to this would also be to change from an "available" metric > to an "anon_reclaimable" metric since both the deferred split queues and > lazy freeable memory would pertain to anon. This would no longer attempt > to mimic MemAvailable and leave any such calculation to userspace > (anon_reclaimable + (file + slab_reclaimable) / 2). > > With this route, care would need to be taken to clearly indicate that > anon_reclaimable is not necessarily a subset of the "anon" metric since > reclaimable memory from compound pages on deferred split queues is not > mapped, so it doesn't show up in NR_ANON_MAPPED. > > I'm indifferent to either approach and would be happy to switch to > anon_reclaimable if others agree and doesn't foresee any extensibility > issues. Agreed, I was also once confused about the 'MemAvailable'. The 'reclaimable' might be better to understand. Thanks, SeongJae Park From mboxrd@z Thu Jan 1 00:00:00 1970 From: SeongJae Park Subject: Re: Re: [patch] mm, memcg: provide a stat to describe reclaimable memory Date: Wed, 15 Jul 2020 09:15:22 +0200 Message-ID: <20200715071522.19663-1-sjpark@amazon.com> References: Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1594797369; x=1626333369; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=HEw3+Ao/fqO9FvXA+Yo3+7G67lorJbwZfAa4e34wU6o=; b=FKkUZ+ixFASeTPY+2m6wAwM0YA2HW9sExpozMrc4IS3oO+zIytEYTxVC wpU5FRBncGRBUhiAI8GKnAVA4ZKnPyXxxBHbNKEho5pnIqDtedmHq559B E5uLm6OHdFZAla1czKEyzvjejFsE8NLosdLwzbR4QM3VcYxD3XKGgoGwR M=; In-Reply-To: (raw) Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: David Rientjes Cc: Andrew Morton , Yang Shi , Michal Hocko , Shakeel Butt , Yang Shi , Roman Gushchin , Greg Thelen , Johannes Weiner , Vladimir Davydov , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org Hello David, On Wed, 15 Jul 2020 00:00:03 -0700 (PDT) David Rientjes wrote: > On Tue, 14 Jul 2020, David Rientjes wrote: > [...] > > An alternative to this would also be to change from an "available" metric > to an "anon_reclaimable" metric since both the deferred split queues and > lazy freeable memory would pertain to anon. This would no longer attempt > to mimic MemAvailable and leave any such calculation to userspace > (anon_reclaimable + (file + slab_reclaimable) / 2). > > With this route, care would need to be taken to clearly indicate that > anon_reclaimable is not necessarily a subset of the "anon" metric since > reclaimable memory from compound pages on deferred split queues is not > mapped, so it doesn't show up in NR_ANON_MAPPED. > > I'm indifferent to either approach and would be happy to switch to > anon_reclaimable if others agree and doesn't foresee any extensibility > issues. Agreed, I was also once confused about the 'MemAvailable'. The 'reclaimable' might be better to understand. Thanks, SeongJae Park