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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,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 D9AABC11F68 for ; Fri, 2 Jul 2021 07:50:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6B704613FC for ; Fri, 2 Jul 2021 07:50:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6B704613FC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=canonical.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F2E976B0011; Fri, 2 Jul 2021 03:50:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EDEB86B0036; Fri, 2 Jul 2021 03:50:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D57CE6B005D; Fri, 2 Jul 2021 03:50:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id AE7516B0011 for ; Fri, 2 Jul 2021 03:50:27 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5E656181D75CB for ; Fri, 2 Jul 2021 07:50:27 +0000 (UTC) X-FDA: 78316875294.23.CD114C8 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by imf10.hostedemail.com (Postfix) with ESMTP id 051966001AA6 for ; Fri, 2 Jul 2021 07:50:26 +0000 (UTC) Received: from mail-ej1-f72.google.com ([209.85.218.72]) by youngberry.canonical.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lzDwP-00036d-Hj for linux-mm@kvack.org; Fri, 02 Jul 2021 07:50:25 +0000 Received: by mail-ej1-f72.google.com with SMTP id d2-20020a1709072722b02904c99c7e6ddfso3229112ejl.15 for ; Fri, 02 Jul 2021 00:50:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=LX1dRRvVTSSNV393pCWC9nqJdkpuDd2IbpTb7ntZCBA=; b=MHrqKXltukHENrdLhn1rId5a4j1EMJLEKyFo/Uz/E18lsMuHtK5wrlabK8QIy1mglg +I4I7bmFj05uhSBpcFQv42R38HLui0Ba/l2KHqGwjwKV83+w+LfrYD4hkFbKARoCthUt HdZFx6pKf5glzvGipjgMwrjKWBnR00QjpMsykUsq0+qpcPzs/XDMmP/6D9fQYgC+g6cD gSNHGxTWle/pWXnwy0VZJCmhkucwxreiGhD/0ONG0w4hui/HvYV7doie6kUmDCnCfW5I Ho+Ddel+QC7nJeonw4lSUDDs3hLVnyLuJBNsFkl4hlLFaqxzcd1UNplB/lahmE6tatCA 1MdQ== X-Gm-Message-State: AOAM53162pJoBIqSKgDNNIw1V2LoI/IRSUe9W/50Hd7AdvAFhEpwtPSq yxxxejoh0juIoNbLAZy4r3DmnIiVDevis92V/l70QhSAZKilMxVksEE5d9zjpU8wHbY/5AKhi3K OG71O+FA9MBk0E/mCSWLLVEHMoFgo X-Received: by 2002:a17:906:5408:: with SMTP id q8mr4057391ejo.2.1625212223878; Fri, 02 Jul 2021 00:50:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzn3Pz/ECVwptULHgdrkCP2GgJ+VIt489u9XMjxuKy+7r78kAJb6kJJzZa8Og93DSoXHL2MuA== X-Received: by 2002:a17:906:5408:: with SMTP id q8mr4057372ejo.2.1625212223633; Fri, 02 Jul 2021 00:50:23 -0700 (PDT) Received: from [192.168.1.115] (xdsl-188-155-177-222.adslplus.ch. [188.155.177.222]) by smtp.gmail.com with ESMTPSA id v24sm940031eds.39.2021.07.02.00.50.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Jul 2021 00:50:12 -0700 (PDT) From: Krzysztof Kozlowski To: Andrew Morton , Johannes Weiner , Michal Hocko , Vladimir Davydov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Process memory accounting (cgroups) accuracy Message-ID: <69ffd3a0-2cb7-8baa-17d0-ae45a52595af@canonical.com> Date: Fri, 2 Jul 2021 09:50:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 051966001AA6 Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=canonical.com (policy=none); spf=none (imf10.hostedemail.com: domain of krzysztof.kozlowski@canonical.com has no SPF policy when checking 91.189.89.112) smtp.mailfrom=krzysztof.kozlowski@canonical.com X-Stat-Signature: 7btx7p3gh61sdpt3zxrr1iw7998ubh63 X-HE-Tag: 1625212226-990994 Content-Transfer-Encoding: quoted-printable 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: Hi, Since some time I am trying to fix Linux Test Project tests around memory cgroups: https://lists.linux.it/pipermail/ltp/2021-June/023259.html The trouble I have, for example with memcg_max_usage_in_bytes_test.sh is that on recent kernels (v4.15+) on x86_64, the memory group reports max usage as higher than process' anonymous mapping. The test works like this: 1. Fork a process, signal it to mmap 4 MB (PROT_WRITE | PROT_READ, AP_PRIVATE | MAP_ANONYMOUS) and touch the memory. 2. Add the process to control group. 3. Signal it to munmap the region and immediately mmap again the same 4 MB (with touching the memory). 4. Check the counters and reset them. 5. munmap 6. Check the counters Mentioned memcg_max_usage_in_bytes_test.sh checks the counters of memory.memsw.max_usage_in_bytes which are: a. early kernels: 4 MB (so only the mmap) b. v4.15, v5.4 kernel: 4 MB + 32 pages c. v5.11 kernel: 4 MB + 32 pages + 2 pages I tweaked the mmap() size to smaller values and then the accounting is even different. For example mmap of 1 up to 32 pages the memory.memsw.max_usage_in_bytes is always 131072. After final munmap (point 5 above), the test expects the memcg_max_usage_in_bytes to be =3D0, however it is usually 8 or 132 kB. Which kind of points that process is charged for something not related to that memory map directly. The questions: How accurate are now the cgroup counters? I understood they should charge only pages allocated by the process, so why mmap(4 kB) causes max_usage_in_bytes=3D132 kB? Why mmap(4 MB) causes max_usage_in_bytes=3D4 MB + 34 pages? What is being accounted there (stack guards?)? Or maybe the entire LTP test checking so carefully memcg limits is useles= s? The v5.4 kernel config is here: https://kernel.ubuntu.com/~kernel-ppa/config/focal/linux-azure/5.4.0-1039= .41/amd64-config.flavour.azure Best regards, Krzysztof