Received: by 2002:a05:7412:da14:b0:e2:908c:2ebd with SMTP id fe20csp575795rdb; Fri, 6 Oct 2023 11:47:28 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHMZg5HQaEen/HKbOdM6nm1Ah2Ztuo1kHGeKmSO9YMqoIiqbaoNTfBzDybWaP/3udwYDGm/ X-Received: by 2002:a05:6808:158:b0:3a7:5309:f1f with SMTP id h24-20020a056808015800b003a753090f1fmr9166388oie.45.1696618048526; Fri, 06 Oct 2023 11:47:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696618048; cv=none; d=google.com; s=arc-20160816; b=Vxk9/duUiB+33Fw4dMuMCxuzv13ePiZ05F6B7+G+odJBRNKjYVJt2RuoMlMtvaMhCl gR8x3pndaTOl5L2EhAK2V4Sj/YQalXiBSAcdFOHuLGDp+MhD1hXtIyZQ8r7eoaqItO4d aHueUiwQnhTG7kysJmjfUaYxaONzKph9WhMWbyx4jZnsBejuq4VWEHlW4oXvRaw7cdQQ rqHg4jQ5njgVfRNUbkM9GD7JFALBGztK5vTmrGLv9NZX5cxEpvFParB5ca+6PZc5Xfwr ss+8bAf5X0sm2K+VXmWiA8Yr7iux5OQp2qb2ei1FkrNnuOV2/iFbyoP4oh2B1D24W9X5 D+3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=2s4i0NFYgIBv1cJZUrejLYvQnyIri0mts0GvRI59+ZQ=; fh=iuOdG2UsaRKUpHOR3B0vXOw1fow3AOmqKEKZ7KuRmaE=; b=mMNfjPVHJyFw3CTGoLW4B8NV7SPruCVxivotWhsjRnGLyAhKTgscFI+x7Bz/1/Fuhx XvoiizPFu+BZGWLbP/9sLAFzRLR7YJx7y4RRcTF6P7atQxrnquaPSjl12/HgIjllkL1r kfRBmGTU7I2jKj9sofGxz5aESG+oq5zUDdKs6PJyyGonjffg+146zGs8MCnIVIdR5wdK XT5vWY63+jEagzGkE49dVtfWvFCpfZBc3djAtL4DC1PCO9aAcm82WtAwetyWHmtwDnkr 4wshM/ksJEmiRsT7s9s4p7guPDGdmOyzFIn+U0s/WzfJOLjgJrs2bhGPpSsDu5DArcH6 QBUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=m71AVx5A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 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 snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id h9-20020a654049000000b0056aa105b6a4si3937303pgp.79.2023.10.06.11.47.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Oct 2023 11:47:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=m71AVx5A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 77838802FBBE; Fri, 6 Oct 2023 11:46:38 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233158AbjJFSqd (ORCPT + 99 others); Fri, 6 Oct 2023 14:46:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233130AbjJFSqc (ORCPT ); Fri, 6 Oct 2023 14:46:32 -0400 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 57D91C6; Fri, 6 Oct 2023 11:46:31 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-69af8a42066so1392393b3a.1; Fri, 06 Oct 2023 11:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696617991; x=1697222791; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=2s4i0NFYgIBv1cJZUrejLYvQnyIri0mts0GvRI59+ZQ=; b=m71AVx5Asuo1MG15b1CAY92Bhkf80JrPz70M8VdbrR6q2eu/Nf+Q8q7i3cyG5ow4eb 8+ukgjpTzNxPPwHBg6wgKZ0zA2hFtF0D7ddIE/gORHKxSSpYIiauq+O12WQawBwVLnc3 SKoOIfjBoUkbylxSveZOEnwbIX2Bo7Kgp3u95WMV9UHe4773EEStyjV4E/mqkBBR3y3m zK2bSxLX7YC2IgRJBpLLZsQmfRYYdMhiNrOaNK6QUKSFzugiRQzZ6S1bN4EVZtHovqlF CnVKzAIBoFiCQ1/kYBbgl+02l0s8YHz/I4zps/W0YcdaLjmDLYzTqCO++nSg5XuLbaWp XL2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696617991; x=1697222791; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2s4i0NFYgIBv1cJZUrejLYvQnyIri0mts0GvRI59+ZQ=; b=qfO56BxcXoiv4E5JNfUbhHfmx+TUReqLOqfjctBbDtUI9/9fjew02nnGdjMsv+S2ap G9Cqj+duq7zMosMPfpAvi3w9lcP9D26aIICD4jiLLGmTYFgma0LChLSj+/YTqJU8h3m9 0mBf8wYtj35VEkdqgDoH5Hn36XZSg7aFIYokZ9oZj1O4I7z6Sx5tRifWwSMJGbHOr/Y9 hlrorw71b+15PtJ3rrIR0RYgtPUv5dGD6kzaRM/9l0caJvzbFhs7q7LCMYEzR15EVfsM 7K9yvykKs40sgT+0Z5IFo+ohov1HLc7UlHqdEjBipi1sM+OahlwUJiP8ZAgdmfq8NkKU PbPg== X-Gm-Message-State: AOJu0YxneR69uGhJY/Q2r8DLScsuyYwK1luBCqIn26HAYANxmIb1ZvpO HLozRSkHMcx9vpYrxxprKfA= X-Received: by 2002:a05:6a20:841b:b0:137:2f8c:fab0 with SMTP id c27-20020a056a20841b00b001372f8cfab0mr10387583pzd.49.1696617990622; Fri, 06 Oct 2023 11:46:30 -0700 (PDT) Received: from localhost (fwdproxy-prn-000.fbsv.net. [2a03:2880:ff::face:b00c]) by smtp.gmail.com with ESMTPSA id v13-20020aa7808d000000b0068ffd4eb66dsm1812830pff.35.2023.10.06.11.46.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Oct 2023 11:46:30 -0700 (PDT) From: Nhat Pham To: akpm@linux-foundation.org Cc: riel@surriel.com, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, tj@kernel.org, lizefan.x@bytedance.com, shuah@kernel.org, mike.kravetz@oracle.com, yosryahmed@google.com, fvdl@google.com, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: [PATCH v4 0/4] hugetlb memcg accounting Date: Fri, 6 Oct 2023 11:46:25 -0700 Message-Id: <20231006184629.155543-1-nphamcs@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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_BLOCKED,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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Fri, 06 Oct 2023 11:46:38 -0700 (PDT) Changelog: v4: * Add another prep patch to clean up memory controller migration logic. * Fix an issue in hugetlb folio migration where the new folio is not properly charged (patch 3) (reported by Mike Kravetz) (suggested by Johannes Weiner). v3: * Add a prep patch at the start of the series to extend the memory controller interface with new helper functions for hugetlb accounting. * Do not account hugetlb memory for memcontroller in cgroup v1 (patch 2) (suggested by Johannes Weiner). * Change the gfp flag passed to mem cgroup charging (patch 2) (suggested by Michal Hocko). * Add caveats to cgroup admin guide and commit changelog (patch 2) (suggested by Michal Hocko). v2: * Add a cgroup mount option to enable/disable the new hugetlb memcg accounting behavior (patch 1) (suggested by Johannes Weiner). * Add a couple more ksft_print_msg() on error to aid debugging when the selftest fails. (patch 2) Currently, hugetlb memory usage is not acounted for in the memory controller, which could lead to memory overprotection for cgroups with hugetlb-backed memory. This has been observed in our production system. For instance, here is one of our usecases: suppose there are two 32G containers. The machine is booted with hugetlb_cma=6G, and each container may or may not use up to 3 gigantic page, depending on the workload within it. The rest is anon, cache, slab, etc. We can set the hugetlb cgroup limit of each cgroup to 3G to enforce hugetlb fairness. But it is very difficult to configure memory.max to keep overall consumption, including anon, cache, slab etc. fair. What we have had to resort to is to constantly poll hugetlb usage and readjust memory.max. Similar procedure is done to other memory limits (memory.low for e.g). However, this is rather cumbersome and buggy. Furthermore, when there is a delay in memory limits correction, (for e.g when hugetlb usage changes within consecutive runs of the userspace agent), the system could be in an over/underprotected state. This patch series rectifies this issue by charging the memcg when the hugetlb folio is allocated, and uncharging when the folio is freed. In addition, a new selftest is added to demonstrate and verify this new behavior. Nhat Pham (4): memcontrol: add helpers for hugetlb memcg accounting memcontrol: only transfer the memcg data for migration hugetlb: memcg: account hugetlb-backed memory in memory controller selftests: add a selftest to verify hugetlb usage in memcg Documentation/admin-guide/cgroup-v2.rst | 29 +++ MAINTAINERS | 2 + include/linux/cgroup-defs.h | 5 + include/linux/memcontrol.h | 37 +++ kernel/cgroup/cgroup.c | 15 +- mm/filemap.c | 2 +- mm/hugetlb.c | 35 ++- mm/memcontrol.c | 139 +++++++++-- mm/migrate.c | 3 +- tools/testing/selftests/cgroup/.gitignore | 1 + tools/testing/selftests/cgroup/Makefile | 2 + .../selftests/cgroup/test_hugetlb_memcg.c | 234 ++++++++++++++++++ 12 files changed, 478 insertions(+), 26 deletions(-) create mode 100644 tools/testing/selftests/cgroup/test_hugetlb_memcg.c -- 2.34.1