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=-5.8 required=3.0 tests=BAYES_00,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 CAAC7C11F68 for ; Fri, 2 Jul 2021 09:08:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6D46D61439 for ; Fri, 2 Jul 2021 09:08:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D46D61439 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BB9A06B0036; Fri, 2 Jul 2021 05:08:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B69B66B005D; Fri, 2 Jul 2021 05:08:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A31416B006C; Fri, 2 Jul 2021 05:08:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0055.hostedemail.com [216.40.44.55]) by kanga.kvack.org (Postfix) with ESMTP id 824036B0036 for ; Fri, 2 Jul 2021 05:08:22 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2C0841F352 for ; Fri, 2 Jul 2021 09:08:22 +0000 (UTC) X-FDA: 78317071644.05.6AB6C41 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf09.hostedemail.com (Postfix) with ESMTP id A91233000375 for ; Fri, 2 Jul 2021 09:08:21 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 4BD262006A; Fri, 2 Jul 2021 09:08:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1625216900; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Vy9xdj2QLgIqzr/TgmLE77gLmPWcB0CW7T+Mjh40YGc=; b=VAQaWwdMVj2o9m81fAuHALE0jIVcwnGjxshViGXKd+wsXn5bTqSdtgFdYG0DDnSmGtE7+u F2s+VgUPZyf2Z8NN1XmybNZgSe0FhTv33uGZZmMsU9Su142BWJIF/s+7Rv6CcvLZVnpuj7 t78uAO9mWgSCzrZheK9G9KPILW5elK4= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 07E27A3B83; Fri, 2 Jul 2021 09:08:19 +0000 (UTC) Date: Fri, 2 Jul 2021 11:08:19 +0200 From: Michal Hocko To: Krzysztof Kozlowski Cc: Andrew Morton , Johannes Weiner , Vladimir Davydov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: Process memory accounting (cgroups) accuracy Message-ID: References: <69ffd3a0-2cb7-8baa-17d0-ae45a52595af@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69ffd3a0-2cb7-8baa-17d0-ae45a52595af@canonical.com> Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=VAQaWwdM; spf=pass (imf09.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: A91233000375 X-Stat-Signature: m45g1skqiuun5kqo3ie3rof3b4ej3goi X-HE-Tag: 1625216901-43523 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 02-07-21 09:50:11, Krzysztof Kozlowski wrote: [...] > The questions: How accurate are now the cgroup counters? The precision depends on the number of CPUs the workload is running on as we do a per-cpu charge caching to optimize the accounting. This is MEMCG_CHARGE_BATCH (32) pages currently. You can learn more by checking try_charge function (mm/memcontrol.c). > I understood they should charge only pages allocated by the process, so > why mmap(4 kB) causes max_usage_in_bytes=132 kB? Please note that kernel allocations (marked by __GFP_ACCOUNT) are accounted as well so this is not only about mmaped memory. > Why mmap(4 MB) causes max_usage_in_bytes=4 MB + 34 pages? The specific number will depend on the executing - e.g. use up all but 3 pages from CPU0 batch and have 31 pages on another cpu. > What is being accounted there (stack guards?)? > > Or maybe the entire LTP test checking so carefully memcg limits is useless? Well, I haven't really checked details of those tests and their objective but aiming for an absolute precision is not really something that is very useful IMHO. We are very likely to do optimizations like the one mentioned above as the runtime tends to be much more important than to-the-page precision. Hope this clarifies this a bit. -- Michal Hocko SUSE Labs