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=-4.0 required=3.0 tests=BAYES_00,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 0B280C433E3 for ; Mon, 20 Jul 2020 07:37:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C88FA2073A for ; Mon, 20 Jul 2020 07:37:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C88FA2073A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 312BE6B0003; Mon, 20 Jul 2020 03:37:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 29C876B0005; Mon, 20 Jul 2020 03:37:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1669A6B0006; Mon, 20 Jul 2020 03:37:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0116.hostedemail.com [216.40.44.116]) by kanga.kvack.org (Postfix) with ESMTP id F04716B0003 for ; Mon, 20 Jul 2020 03:37:56 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5E22418D180 for ; Mon, 20 Jul 2020 07:37:56 +0000 (UTC) X-FDA: 77057650152.30.brick89_0e07f8826f23 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id D8C26180ADC29 for ; Mon, 20 Jul 2020 07:37:18 +0000 (UTC) X-HE-Tag: brick89_0e07f8826f23 X-Filterd-Recvd-Size: 4075 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jul 2020 07:37:18 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id q15so21237697wmj.2 for ; Mon, 20 Jul 2020 00:37:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3+cG4dlbvOXxi0Np/998Id6Ue/YJ51oIXoz1t5uzjEE=; b=cR+AE09O+X312vNXdVQr627le8Dye16JdPhEdnBac9gk3DxBAFSeKaWwO8EsdFQgLB 8pvr78kAmAWwuI4pAq/ReSMfkMUigOJyt/366EupzVyiuIiBJ6GskfFGfdBO8ojg/6GS sB0q3hF7OKXzoodzZeBuRm9pwP5dQaiu21qIsaW9xoyZiz/5kgMydQEBgPlFtz+q3IIo IMIyyMQ7LwF+gyP6cDMBa3I1rlpg2OHRQiQBqKaVxKH1DpLlzt8rb/B9oZIPNALTu3fx ZYQ3w2or3O8TlktCjfwnt3081b3lHEtaYax7uSOD1eS2RUtXo97lOXRrrq9adagEeZGC hffQ== X-Gm-Message-State: AOAM533RjsmB6dAxA9IqACTq7wtCh291Hxfnf/AZmJYHlExkui7GpgWT He7DGdC7eK5HAABfmyk9DYI= X-Google-Smtp-Source: ABdhPJw0egh+vZOpf+3Q1sE4MGaAhEuhbo9dtC8o+ihIP20N5BB4q51xtPRvHWzAipyqdcTdnmOtOw== X-Received: by 2002:a05:600c:2949:: with SMTP id n9mr19440283wmd.69.1595230637370; Mon, 20 Jul 2020 00:37:17 -0700 (PDT) Received: from localhost (ip-37-188-169-187.eurotel.cz. [37.188.169.187]) by smtp.gmail.com with ESMTPSA id p29sm32231242wmi.43.2020.07.20.00.37.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2020 00:37:16 -0700 (PDT) Date: Mon, 20 Jul 2020 09:37:15 +0200 From: Michal Hocko To: David Rientjes Cc: Chris Down , Andrew Morton , Yang Shi , Shakeel Butt , Yang Shi , Roman Gushchin , Greg Thelen , Johannes Weiner , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch] mm, memcg: provide a stat to describe reclaimable memory Message-ID: <20200720073715.GB18535@dhcp22.suse.cz> References: <20200715131048.GA176092@chrisdown.name> <20200717121750.GA367633@chrisdown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: D8C26180ADC29 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Fri 17-07-20 12:37:57, David Rientjes wrote: [...] > On a 4.3 kernel, for example, memory.current for the heap segment is now > (64MB / 2MB) * 4KB = 128KB because we have synchronous splitting and > uncharging of the underlying hugepage. On a 4.15 kernel, for example, > memory.current is still 64MB because the underlying hugepages are still > charged to the memcg due to deferred split queues. Deferred THP split should be a kernel internal implementation optimization and a detail that userspace shouldn't really be worrying about. If there are user visible effects that are standing in the way then we should reconsider how much is the optimization worth. I do not really remember any actual numbers that would strongly justify its existence while I do remember several problems that this has introduced. So I am really wondering whether exporting subtle metrics to the userspace which can lead to confusion is the right approach to the problem you have at hands. Also could you be more specific about the numbers we are talking here? E.g. what is the overal percentage of the "mis-accounted" split THPs wrt. to the high/max limit? Is the userspace relying on very precise numbers? -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Subject: Re: [patch] mm, memcg: provide a stat to describe reclaimable memory Date: Mon, 20 Jul 2020 09:37:15 +0200 Message-ID: <20200720073715.GB18535@dhcp22.suse.cz> References: <20200715131048.GA176092@chrisdown.name> <20200717121750.GA367633@chrisdown.name> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: David Rientjes Cc: Chris Down , Andrew Morton , Yang Shi , Shakeel Butt , Yang Shi , Roman Gushchin , Greg Thelen , Johannes Weiner , Vladimir Davydov , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org On Fri 17-07-20 12:37:57, David Rientjes wrote: [...] > On a 4.3 kernel, for example, memory.current for the heap segment is now > (64MB / 2MB) * 4KB = 128KB because we have synchronous splitting and > uncharging of the underlying hugepage. On a 4.15 kernel, for example, > memory.current is still 64MB because the underlying hugepages are still > charged to the memcg due to deferred split queues. Deferred THP split should be a kernel internal implementation optimization and a detail that userspace shouldn't really be worrying about. If there are user visible effects that are standing in the way then we should reconsider how much is the optimization worth. I do not really remember any actual numbers that would strongly justify its existence while I do remember several problems that this has introduced. So I am really wondering whether exporting subtle metrics to the userspace which can lead to confusion is the right approach to the problem you have at hands. Also could you be more specific about the numbers we are talking here? E.g. what is the overal percentage of the "mis-accounted" split THPs wrt. to the high/max limit? Is the userspace relying on very precise numbers? -- Michal Hocko SUSE Labs