Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp1744766rwl; Wed, 12 Apr 2023 18:23:44 -0700 (PDT) X-Google-Smtp-Source: AKy350b2qeQwHpa94p2iTJSVxDuYy+UYmwKb+SilS2aocNzToJIA2b7OJBrwfmXe4eL0GHNSPKy/ X-Received: by 2002:a05:6a00:240b:b0:637:c959:8ea1 with SMTP id z11-20020a056a00240b00b00637c9598ea1mr1029259pfh.22.1681349024179; Wed, 12 Apr 2023 18:23:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681349024; cv=none; d=google.com; s=arc-20160816; b=K2X/PDlR/Cf7eTDaYY4k6mfbYWzDHDlAM9I02P14hPIihNW+qbWNVdwqsskuv5D9kA RfY8cTREfE+uA3rs402KNc6pkvmiRj3UubT7POa6P6IJcWNg9EDCgltSza2OO6FN9xEP VJofFUWwOOpLBfKjtgFLkCAJVLjuuBmElqcjciSpkgGSrKsIIKGUKICQ6U+1WdjHQayO GRTDdMp04fr3H6gEUYw62Ee4grLhBgoKOMQz9As1hFJkgVrVLgArzJIrCD9XVF1or6TS WDTy8XM6RSbFT5pwdXaK7VDuaf/CJ8F8gaoMwD5VPjRPfEEmFHNh8qe9ay+qDgMCf+6z vx5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:subject:message-id:date:from:mime-version :dkim-signature; bh=yuLz9iUc1y0EzGD8AvN7Y9hf2MbqyBOWJrZZ7t76bGM=; b=ZvhnGIWbxrO7SCGBKC9bgtMcS4Iyyl/fAE5WReagajc9nMjsHAG65wjKxfU0Sun68Q NW1MQ1wr99XM8gOHHfqh7aXLZCOVD9y+ZYjnOaBrcxoi82JaoF1PpAblsyXT4TwCUSYF QWflWN0VMnDGJukLWhfjsaZJdYFdCCcMMYzBiV5MMPgSJm5SMhZYt4p8ML0XS15wv6Zn 5lz8WUtW97X7a/g5aWPckE0sllQouw55fwcB+PmZO5eMcXVAPwj2KtC8ipPdjCXgsKqc XSolwhsbx5FlrT2l1Jw5bQRcoFJYyIRu4VbJ6VbFLj4PsZbV7ge8DzG6zy4iOOJpmmZ8 jvjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=Qm1WsHGG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x191-20020a6386c8000000b005137a0eb906si651683pgd.684.2023.04.12.18.23.30; Wed, 12 Apr 2023 18:23:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=Qm1WsHGG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229526AbjDMBWX (ORCPT + 99 others); Wed, 12 Apr 2023 21:22:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbjDMBWW (ORCPT ); Wed, 12 Apr 2023 21:22:22 -0400 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C3D8CF; Wed, 12 Apr 2023 18:22:21 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-504eb1155d3so5855438a12.1; Wed, 12 Apr 2023 18:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681348939; x=1683940939; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=yuLz9iUc1y0EzGD8AvN7Y9hf2MbqyBOWJrZZ7t76bGM=; b=Qm1WsHGG7Yawgtzf4UmTBwdzPBribr4bXLa944+d8dBqQyTYUQfDHQZajmMCidQnYP xxG5hyrsJ2DK2CdZYveJeig/i6zy/sZrjcBmabkbeSIMyEFp++itkqfydZVNXe1Xwalf GwmnvJaELevvy9wCBHSGrGpeZy3su2Ctk+vz0EeQ1emZnnqtL8VPrGgjv+EOD4tVAZKw K6KcRffpQddB4a3aHCnM2MLlY4SMpNcrxIF6I/VByUKw7OBIzoCx18lRrzYobBBdisIz 9efZAtqGXAEit6kb/SQ9r3xk8M9yDb40noKlzK+qv9CqBfC3IYeinDiA16mzgJPo4cEZ MlAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681348939; x=1683940939; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yuLz9iUc1y0EzGD8AvN7Y9hf2MbqyBOWJrZZ7t76bGM=; b=LHeTI464stjRjhrLgobNmtCK07ZfoRDcS+78P0/1tSvFKQQ6y8yA0CH1udLSuiVlS7 ppL+9MOMgEtMsS57Zgmxv6h650OW+Me8E05BYXpm2H+ciK0JUomb0N66Nebj/104lvnQ V7QLPkau8nW1mSBx+kY+ewB2Fdd3J2GYXxqGlHOs92ysTtPvwji0Im603HoVvAdVSsRf heKtXKKR3zkKebXp3s0k39Whz84PCXg411otIUiw4OZ/KfvAwkIj9FTff3HZJdDOC/ZF 2fWLc8wauGpZB/2hwMtYgBcC0F7CKKI1gvqknnP080NFYTQk85ZfjV2ZISme5DDLawOu q8Lw== X-Gm-Message-State: AAQBX9fKAERSlqE44QWre7mOk74ChOXarYnWsMj0oFkpChKWsCrD/wTy r1C1QXNM6f6eY4TatgQjn/uQl3LUkF5xxjS3DLTbrPthuBFenQ== X-Received: by 2002:a05:6402:22f2:b0:506:6a99:ef53 with SMTP id dn18-20020a05640222f200b005066a99ef53mr949787edb.2.1681348939015; Wed, 12 Apr 2023 18:22:19 -0700 (PDT) MIME-Version: 1.0 From: Michael Honaker Date: Wed, 12 Apr 2023 21:22:07 -0400 Message-ID: Subject: cgroup: Clarification around usage_in_bytes and its relation to the page counter To: cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, This is my first posting to the LKML, so please let me know if this should be asked elsewhere or if there is anything else wrong with my email. I'd like to confirm my understanding on an issue I've been encountering. I have been trying to get an accurate measurement of memory usage of a non-root cgroup, specifically a Kubernetes container, and noticed some inconsistencies when comparing the value of `memory.usage_in_bytes` with the information in `memory.stat`. After further investigation of the cgroup docs (/admin-guide/cgroups/memory.rst#usage_in_bytes) and an old LMKL thread ("real meaning of memory.usage_in_bytes"), I came to the understanding that `usage_in_bytes` actually shows the value of the resource counter which is an overestimation due to the counter being split into per-cpu chunks for caching, and that the real usage can be calculated from RSS+Cache gathered from `memory.stat`. I've created cadvisor issue #3286 (https://github.com/google/cadvisor/issues/3286) which goes into greater detail on my investigation with examples. Is the above understanding still correct with the new page counters? If so, could any memory allocations be reflected in `usage_in_bytes` but not in `stat` for child cgroups? I want to ensure I'm not missing anything by only monitoring the `stat` file. Thank you for any clarification or corrections.