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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCC76C10DCE for ; Sat, 2 Dec 2023 08:31:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230218AbjLBIb1 (ORCPT ); Sat, 2 Dec 2023 03:31:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229379AbjLBIbZ (ORCPT ); Sat, 2 Dec 2023 03:31:25 -0500 Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 573AA19F for ; Sat, 2 Dec 2023 00:31:32 -0800 (PST) Received: by mail-pj1-x1049.google.com with SMTP id 98e67ed59e1d1-285d331c6f7so3115018a91.0 for ; Sat, 02 Dec 2023 00:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701505892; x=1702110692; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=RsUdxN3rEKIxfrBuDtxm58n3Q5/dFJQLUdAs66Hut1M=; b=MShJEUEzENjNwWoJezzhBQZOjctUkNEpt0Ur0LcriNCkEPkJeXV5Hzt48ikjmbdlEE 4flTeoovGc5J98C7K3KrUu4jD+0HvgvrVmcdP/u8qws8PPFg76fveDJqvW17GIUXSWF9 MZMpFttgoyDmuUBDlk300DRq9QaQnAk8ntLudSo3TY6RLVtlPSLF4SGaetiyTTYGk+J1 bC9fCyBk4Bbrq8v1wiZP5IiFnl9aY7eu/Etb8L0QR3TXxNAB1U46XPCvEiH3B0bTQJKK 9ojkRXjzqwUbWbNQG8PJLwX0SeZj4LCooIycUA5Iic8r4v++IpRCuc6KsikZYVajxep2 LNmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701505892; x=1702110692; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RsUdxN3rEKIxfrBuDtxm58n3Q5/dFJQLUdAs66Hut1M=; b=PJUC95PzX5Y0WzrZC8K3JYEGRhmD0mDsCiVYoAxhIGmFYKq355H6j/IVRwBABrd5AM wGh51qM7B6JreeWX05oHaXVvRlgFf+mMOcIbA0wkN1y7d7DLVTkTktunFKFeoobbXBu0 /YzVWQXtxKCzCM3c1xopCLt6YcA0JwLSHZmpNA0mYu1nBD9Liz/9zXkUilUuzP9FFx18 f7DevRMmm3p6pNanwgPlQh4bnnFYQIKHa8LGUj4NOTPr4IsIg9+UKaFJUhwdU3bJ1lMJ lDVMCoaxUsxFMJNYOkNjfBHgMSwxX+Sd+cGTOxr0bcFxM1iBw+dIlksx+uK1Wd+i6t6q 4rkA== X-Gm-Message-State: AOJu0YxQJqiyScw19mR5Aa6vbLUWHYRcJIWkvsIfyWo1TlnAceo0pK7t B34lKMGMxu0jz+IleYzSCznlegdLq9ocoA== X-Google-Smtp-Source: AGHT+IF4f5vUtic/5wEWsO4maQQ3yGnMxcSHVpbovj/TMUbKq4uvbD+NDX7zW2s8EKvkAZHr3JG7LPHRBRuUXQ== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a63:d249:0:b0:5bd:408a:5e1f with SMTP id t9-20020a63d249000000b005bd408a5e1fmr4143862pgi.3.1701505891574; Sat, 02 Dec 2023 00:31:31 -0800 (PST) Date: Sat, 2 Dec 2023 08:31:29 +0000 In-Reply-To: <20231129032154.3710765-6-yosryahmed@google.com> Mime-Version: 1.0 References: <20231129032154.3710765-1-yosryahmed@google.com> <20231129032154.3710765-6-yosryahmed@google.com> Message-ID: <20231202083129.3pmds2cddy765szr@google.com> Subject: Re: [mm-unstable v4 5/5] mm: memcg: restore subtree stats flushing From: Shakeel Butt To: Yosry Ahmed Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Ivan Babrou , Tejun Heo , "Michal =?utf-8?Q?Koutn=C3=BD?=" , Waiman Long , kernel-team@cloudflare.com, Wei Xu , Greg Thelen , Domenico Cerasuolo , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 29, 2023 at 03:21:53AM +0000, Yosry Ahmed wrote: [...] > +void mem_cgroup_flush_stats(struct mem_cgroup *memcg) > { > - if (memcg_should_flush_stats(root_mem_cgroup)) > - do_flush_stats(); > + static DEFINE_MUTEX(memcg_stats_flush_mutex); > + > + if (mem_cgroup_disabled()) > + return; > + > + if (!memcg) > + memcg = root_mem_cgroup; > + > + if (memcg_should_flush_stats(memcg)) { > + mutex_lock(&memcg_stats_flush_mutex); What's the point of this mutex now? What is it providing? I understand we can not try_lock here due to targeted flushing. Why not just let the global rstat serialize the flushes? Actually this mutex can cause latency hiccups as the mutex owner can get resched during flush and then no one can flush for a potentially long time. > + /* Check again after locking, another flush may have occurred */ > + if (memcg_should_flush_stats(memcg)) > + do_flush_stats(memcg); > + mutex_unlock(&memcg_stats_flush_mutex); > + } > }