Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp5133128rwl; Mon, 3 Apr 2023 15:04:54 -0700 (PDT) X-Google-Smtp-Source: AKy350YQENXCwF/wv1qpwoCcR26K3R1p60gaoGjnDxARfa1cJKK9jazecLbpQX36RkmJ4SlfWGHl X-Received: by 2002:a05:6a20:8b9e:b0:cc:c5db:ea4a with SMTP id m30-20020a056a208b9e00b000ccc5dbea4amr162064pzh.33.1680559494425; Mon, 03 Apr 2023 15:04:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680559494; cv=none; d=google.com; s=arc-20160816; b=wYI2KLnwYLUSoF7yBOPP5HizHWPyqbtxiFyxF5scJxKUADkpi673qo+IpkJZ58ckaE jht+IWf0MROdEFeMgIji52eX6XFcBsFNbOkYsArzT+PoAg7yfqGj8qOOLpPtzEF+uCZ4 kcs+8m3a6zj5TEse9fB9psVoCTJw/SdvYdhZVCh70C1g5sEsJcKzP/TjQV1UIJLjZDNZ RSVrBkpmCVSQLrsitS6lXPe+z3fMFuWBVe6oQm6FfmW0ThDHxnFdvFGlkDiDkOklsIhJ Hor1XkmNn8kQWU2qI7cngQhqAKT2i+RpC5N5T2s8EQh+dnl+NdMK+ST0lPZntfXp7BPs Fq/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=Oudpa17NQV9icHAF4JVW0zNdSUdsNavz+h9FQ4FdLBA=; b=e9W1pjV7tOmv4F8M66P/kNj6izYjha6SEYbauDJ+OfvvfPiLVV5QmuoSOM+cTGnl8g HfCTSdTqyBiWv958Vkz5f4DEMvPUt50vZHdiPCJh7reYoP8dlfQVszWAvGGRCGVh+DvF SVAVXFgfSfMuujh5zAtr+OccoqoFq+/J7ub4MB1CU0gcgmFREY7aa/B0hqd2+xz4LpV0 c60QyicK0dcRfQj/+a3fQNphGu0df5llWCWGE+hz8iV+V5yr4OMw37iNs5cFw9+MSTAy 8ZosS7FjbZE/V5KojlYcepuxjUS66HpG2l6QL7VUgkzL+jwHl0vyBTL6qdQczl9djoeN cYxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=gmD3EzUX; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a38-20020a631a26000000b005096eb1dabbsi8291378pga.716.2023.04.03.15.04.42; Mon, 03 Apr 2023 15:04:54 -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=@google.com header.s=20210112 header.b=gmD3EzUX; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233565AbjDCWDo (ORCPT + 99 others); Mon, 3 Apr 2023 18:03:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233294AbjDCWDm (ORCPT ); Mon, 3 Apr 2023 18:03:42 -0400 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B2ED26A2 for ; Mon, 3 Apr 2023 15:03:40 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id 20-20020a630514000000b0050bed8b0b61so8899491pgf.11 for ; Mon, 03 Apr 2023 15:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680559419; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=Oudpa17NQV9icHAF4JVW0zNdSUdsNavz+h9FQ4FdLBA=; b=gmD3EzUX38OVjaGFgrpka4qXeIu+V1DoGMvDe0eWXeLuVA1CJdcNcSnyr+n+EpIa7P 3MzjOnSmoFXG3JxX7Cs0Wn8GkvgBkLa16nyiWlhViz9Kto3HXhbMSTrrqLF92l4pjOwM Bl/A9PadEA4W2+qgRGAzaoQf4/LsxKQq3zYjYpbh+vXPlDzaJ4S4K1nV++HobeWezLIl 5VMhWDSPBl0YL4XGy/N1tyENDpHWNaUPOK4Xcs933WjQ4R2VnAzEP/q0VSAq3rp+G1sc XYLTFN0b46pCsuwvdg0Q0NbrDy9LoUkmRlggmmc6W32L6LZuB1HPkybaEDU5BBFcgTTW Tt7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680559419; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Oudpa17NQV9icHAF4JVW0zNdSUdsNavz+h9FQ4FdLBA=; b=B8CEGfW2t8cdJ6k1utbI3PAvFHhLyfV8r+1pL2Hr0GzPhhyvwfa4wvajf3hqgouKJq fcwd4u8hA55WkAGMkI8Dw6Xp8LQ8M2Pkn+Mw98vHXb+O1Ss5zm3/tuh1YV9+92eG3kJ9 7YXR1FeCXQDDD9A3BgKIIDdD3p4EwhlJxiofhm84HIIoaCUD2f9PQ/di+q3CwRz6NoZ0 X8AoGAqD92txq7y8OVWs0Hyw6Qjcbxq9Vo65n2QujmekqcTJxpY0pWlNmyH3ycakNOzX 7NnlxgPHfwOVv9eI8sTt6BveJAQka1Bb8eXoj9Bq/5FwM7DJGnUJTaXDLiUVFeK/auYr +RBw== X-Gm-Message-State: AAQBX9e5SILrfWT5HlnkzjLjoNAnYj5q+7aube4W0crKezejJhS4XKXj H+rb5sbssW7EB30zS3ho5JspOAlP5YyLu2Ug X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:2327]) (user=yosryahmed job=sendgmr) by 2002:a17:902:9b91:b0:1a1:9015:4d5c with SMTP id y17-20020a1709029b9100b001a190154d5cmr211513plp.3.1680559419448; Mon, 03 Apr 2023 15:03:39 -0700 (PDT) Date: Mon, 3 Apr 2023 22:03:32 +0000 Mime-Version: 1.0 X-Mailer: git-send-email 2.40.0.348.gf938b09366-goog Message-ID: <20230403220337.443510-1-yosryahmed@google.com> Subject: [PATCH mm-unstable RFC 0/5] cgroup: eliminate atomic rstat From: Yosry Ahmed To: Alexander Viro , Christian Brauner , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Yosry Ahmed Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.7 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 A previous patch series ([1] currently in mm-unstable) changed most atomic rstat flushing contexts to become non-atomic. This was done to avoid an expensive operation that scales with # cgroups and # cpus to happen with irqs disabled and scheduling not permitted. There were two remaining atomic flushing contexts after that series. This series tries to eliminate them as well, eliminating atomic rstat flushing completely. The two remaining atomic flushing contexts are: (a) wb_over_bg_thresh()->mem_cgroup_wb_stats() (b) mem_cgroup_threshold()->mem_cgroup_usage() For (a), flushing needs to be atomic as wb_writeback() calls wb_over_bg_thresh() with a spinlock held. However, it seems like the call to wb_over_bg_thresh() doesn't need to be protected by that spinlock, so this series proposes a refactoring that moves the call outside the lock criticial section and makes the stats flushing in mem_cgroup_wb_stats() non-atomic. For (b), flushing needs to be atomic as mem_cgroup_threshold() is called with irqs disabled. We only flush the stats when calculating the root usage, as it is approximated as the sum of some memcg stats (file, anon, and optionally swap) instead of the conventional page counter. This series proposes changing this calculation to use the global stats instead, eliminating the need for a memcg stat flush. After these 2 contexts are eliminated, we no longer need mem_cgroup_flush_stats_atomic() or cgroup_rstat_flush_atomic(). We can remove them and simplify the code. Yosry Ahmed (5): writeback: move wb_over_bg_thresh() call outside lock section memcg: flush stats non-atomically in mem_cgroup_wb_stats() memcg: calculate root usage from global state memcg: remove mem_cgroup_flush_stats_atomic() cgroup: remove cgroup_rstat_flush_atomic() fs/fs-writeback.c | 16 +++++++---- include/linux/cgroup.h | 1 - include/linux/memcontrol.h | 5 ---- kernel/cgroup/rstat.c | 26 ++++-------------- mm/memcontrol.c | 54 ++++++++------------------------------ 5 files changed, 27 insertions(+), 75 deletions(-) -- 2.40.0.348.gf938b09366-goog