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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D2E3C001DB for ; Tue, 15 Aug 2023 00:30:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B0C7B900011; Mon, 14 Aug 2023 20:30:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ABCED90000B; Mon, 14 Aug 2023 20:30:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9AC9E900011; Mon, 14 Aug 2023 20:30:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8956290000B for ; Mon, 14 Aug 2023 20:30:26 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 5532CB2307 for ; Tue, 15 Aug 2023 00:30:26 +0000 (UTC) X-FDA: 81124457652.29.3F725E6 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by imf10.hostedemail.com (Postfix) with ESMTP id 71E3EC0022 for ; Tue, 15 Aug 2023 00:30:24 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=cloudflare.com header.s=google header.b=CxLgfRZT; spf=pass (imf10.hostedemail.com: domain of ivan@cloudflare.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=ivan@cloudflare.com; dmarc=pass (policy=reject) header.from=cloudflare.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692059424; a=rsa-sha256; cv=none; b=t03AU6i/lXIEBizrj3/c+xyI0KtxQYxcakLyUNZ0cI58KuRxdNUoBnqoZw79OQQpHR+jBM SOFNPYiei8HW+JeTfp0lvNpfiS4BtxXUrRqGnqaTsRtWg6ON2aNejhfjc7eCXEFhCv9mLQ QIgxUyLH7lyDjaC4dFoPXDQWVRpdDr0= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=cloudflare.com header.s=google header.b=CxLgfRZT; spf=pass (imf10.hostedemail.com: domain of ivan@cloudflare.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=ivan@cloudflare.com; dmarc=pass (policy=reject) header.from=cloudflare.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692059424; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=dLuShFOThvoDFyPjtjqSrXce/+NsjfeL6FKbvb91ep0=; b=Z4aDHqsZRpaZlJxQ5Qh+iWgxdea576+4QqEvICdK6ZDPdIwp468hpzVSP4PodFVHxl/zc/ +TMwK0uhXhMboNA/G2Kte5eYDAntLg8J1TgOOd490QZhs0aQ6JFOqW5ctJDnkC+4nZPJZc 8STpJeEXhRcGiNGtQQo16mor0s72kqE= Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-3fe2ba3e260so48302915e9.2 for ; Mon, 14 Aug 2023 17:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; t=1692059423; x=1692664223; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dLuShFOThvoDFyPjtjqSrXce/+NsjfeL6FKbvb91ep0=; b=CxLgfRZTYE2O+lvzzG0vY5ne298WWrrJYUWkVxMZpLYYaHsHujbTYL5pjKgETSom8D vzAAqqBkpXkWiv0++Uxv0ACgo3g3wnwX2egyTis+N6wLSzvjoT/n1He6wzKIsNcmOJPd u2v+6Q1C4+SciYbUN3OI8YjqnJpbMRUzxEYaE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692059423; x=1692664223; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dLuShFOThvoDFyPjtjqSrXce/+NsjfeL6FKbvb91ep0=; b=F0am072I53Z67aZ30l3D0oS0ffup9EUvX2Xh9YsaQ6fVRn3hw1wVPAcp0ioCm9LhOK lpzZBqzi6clKBvg8vZzaVvZVutl3VQqwy/0kTfLpq5FQ8Si5DA2LfFDNhIiLD4+8RGky LoECcryyWgAz+CPGUWS0SJsdI1kjgrVn6gf6sH4AJtuK/gbrhJRpvskdjJK7xgcrv79t p/bJR/OnRAqq759iCuxvtIR08uVY+WWG+TgJKUCU2Dty/wdkXJdzr5kJvS7avd4OHqqd VadJKlYl8iBMB3AnrJ0vgNXE42F7lLW82VlU+7OUb66wR+HsmFr8rdWjwMesXpx77qUf XqZg== X-Gm-Message-State: AOJu0YycicMl9ZIPK+Wog1S0SCXmjvTlaQAdmbP6+J0mBtxOsFNOrPaQ Xech6UN1gTT4kMxSJ8HOrMyHxjK57iTDhL61izH50g== X-Google-Smtp-Source: AGHT+IGyNYUpfBkaRUehRFQ2BJSXZpWDK4rzsea/ReN61axbfTfPHR5q7HWor/xA/ao4HC/HTFvoIKofUvPoizB2tp4= X-Received: by 2002:a05:600c:3648:b0:3fd:29cf:20c5 with SMTP id y8-20020a05600c364800b003fd29cf20c5mr8857963wmq.7.1692059423025; Mon, 14 Aug 2023 17:30:23 -0700 (PDT) MIME-Version: 1.0 References: <20230706062045.xwmwns7cm4fxd7iu@google.com> In-Reply-To: From: Ivan Babrou Date: Mon, 14 Aug 2023 17:30:11 -0700 Message-ID: Subject: Re: Expensive memory.stat + cpu.stat reads To: Tejun Heo Cc: Yosry Ahmed , Waiman Long , Shakeel Butt , cgroups@vger.kernel.org, Linux MM , kernel-team , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Andrew Morton , linux-kernel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 71E3EC0022 X-Stat-Signature: goeq8do4xz91en1h3tfh1iw1upoaumw5 X-Rspam-User: X-HE-Tag: 1692059424-809192 X-HE-Meta: U2FsdGVkX19oG/c1+JIx60j0LfGemuQ8X/HrnYuoPT95KshuNz2kEHk9lEPD0MBz/nlvp7mkbLfgzmqhR94KnPz4+ycZ5Q6KloVXWFQNn+hhbWAs11VDVFIMWDAm9k6zhiesJYv7xOA2zwPQfYef1femqaa/f684aW6Qv7ySiELp0tgzHYXrOfNPwriVI+74fcyqePyHZUYAe4e4F0VO3iyenPXAC3q8dSuzPH8+gjsMfm8IaXDQ8g62i/igfll2UzrsSsD2z4h3HLvE4gg6dhdvuH8C/bZ7cSPegpl2RIlK0t+aBYJZgRFw3UDLzeL9q9FYl9jN39sL49VwSzJJzRmLP1IjC2T3FGPI38oC9lJQC3jYcU6Zjfi8P8E95L+bfAhmoh1PFZsgwLtkloQakftRRB7I/j2eat+hSN+2bC4neNQZT1fl1c3abpu6Y+2nCf3bkYW43qpc+0SPKtSIFiMcIfgJK9f3zkeDyUwAyZ+CYM8or1Q6CFbiUijjF8PmwJ9S40Pu2nK3xDa8NeBMxrIVh02X22b7XatqO9jfF34A0HsNolTQgngjZx2KH0PkUNWkiMWH7TiCrX1vpWArI/PlLCeB+0sF7XHsox/CjiGZXt0AM1o0XhEXgL1NdT4W3jX2oCuhoTAWF/Jve3kQrmClnwQQjSzEcT/s7ZgjBSOpC8wHHogU1MwFgcSCj45gm5r1nJKoUkFS7ED9oC/EfrzmjAnNloi/HhJnuE+kP++7wsqcgZhh01izyQfCuZg5q8Q3QlKRcHABkYxU20fUrT/RjLRE3qXREdV+f8g5UjZGQnufsxgymPpGsyxjOkemdkl21OKpJ/IZTwWS/ByHmCEoC4LB8aCGE18TcYlw8Chi14RRJ75Qojz0gp+YPevsVqV1Y1WhUWE+IE7Gxs3LuHuMnUbNz2MgJMqLnqu5V2t/D3ZpGiIE8md/nFHyrRFnpG6GNrj9dmgWX/6BbS9 tH+ntxwB MEM+1NVLWPN5bppC+ImYl//dwgh7ImcuUn4VbDEPACXI3B88XvnQ2/ryiQCQBjqwy70ebadStg+7q/2Ah/vYMUXMEkV096Fe2x3cufVr2wnz0t1K3StaSiwxr+aq1IWXAzrp9PxUy0UTopZSTshDK8MDsdVC32+Hu2MSTnz4lH4DV+ZOF6Pv8lpcKYZbEco4T7BWWWlVi6PPnOOjj0lW83W2s+N+UUv91OjgnopDrHvs8VhSrZPIOyRMPt9COcEJeo/imiii6a4wTh30xvuCg1AhyitbdX9rzMFw0xr6PDMFj8aU= 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: On Mon, Aug 14, 2023 at 5:18=E2=80=AFPM Tejun Heo wrote: > > Hello, > > On Fri, Aug 11, 2023 at 05:01:08PM -0700, Yosry Ahmed wrote: > > There have been a lot of problems coming from this global rstat lock: > > hard lockups (when we used to flush atomically), unified flushing > > being expensive, skipping flushing being inaccurate, etc. > > > > I wonder if it's time to rethink this lock and break it down into > > granular locks. Perhaps a per-cgroup lock, and develop a locking > > scheme where you always lock a parent then a child, then flush the > > child and unlock it and move to the next child, etc. This will allow > > concurrent flushing of non-root cgroups. Even when flushing the root, > > if we flush all its children first without locking the root, then only > > lock the root when flushing the top-level children, then some level of > > concurrency can be achieved. > > > > Maybe this is too complicated, I never tried to implement it, but I > > have been bouncing around this idea in my head for a while now. > > > > We can also split the update tree per controller. As far as I can tell > > there is no reason to flush cpu stats for example when someone wants > > to read memory stats. > > There's another thread. Let's continue there but I'm a bit skeptical whet= her > splitting the lock is a good solution here. Regardless of locking, we don= 't > want to run in an atomic context for that long anwyay. Could you link to the other thread?