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 1D5D0C6FA8F for ; Thu, 24 Aug 2023 18:16:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 628A3280063; Thu, 24 Aug 2023 14:16:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D9018E0011; Thu, 24 Aug 2023 14:16:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A0BF280063; Thu, 24 Aug 2023 14:16:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 37B388E0011 for ; Thu, 24 Aug 2023 14:16:27 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id F33A81C95F5 for ; Thu, 24 Aug 2023 18:16:26 +0000 (UTC) X-FDA: 81159803214.19.6FE0057 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf28.hostedemail.com (Postfix) with ESMTP id 1926BC002B for ; Thu, 24 Aug 2023 18:16:24 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=P7byTXhX; spf=pass (imf28.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692900985; a=rsa-sha256; cv=none; b=0k3TWStVyWR9TDuJ/ovvd7HjNe3HbaTX1dZNhEEh6UCEIbAj8wwzTKLrGLRYgQn9lFjjGe /K/RP/JAvVhLrirYk2xrrVmQyQlYxwgRdCgIJTx8C6kigx16Vcbx1d7UCD2nY/BwAMHWXQ O+hVFCUOps+7TCdADdU2yCB/uRHib9k= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=P7byTXhX; spf=pass (imf28.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692900985; 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=7V339yE8bPMm+KmAAdyGZ6ExwOtcmP76lDiycvZ+QhM=; b=EB3dSLCxsCbWUz96gGQFUdhnMaZALfUIFtxyBE51pR6zdKmxgJcqiWGauNZ9y7VaYOppsF WjqS2ZBOU7xiGvb5NjRbaxO9qHwtdDTeu2O2cpkVHn7bG2AGV2buYXNz+6/HzQ4q198r/x AMJ13Uc6J+3pitD35UVExMnJJSG9Ty0= Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2b974031aeaso1328081fa.0 for ; Thu, 24 Aug 2023 11:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692900983; x=1693505783; 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=7V339yE8bPMm+KmAAdyGZ6ExwOtcmP76lDiycvZ+QhM=; b=P7byTXhX2Ze5Ua+2lm2QhtKtc3P56x6cahDM1celc3QwjF0+Ix+nBD+S1+b0WJDZCI 6IxZTNq5SGvVmyLTnhZ8Bo1bXlPtpi7L/5qqwTm0JgNJJxJmI8jfnwNCEIB6gnl1srAD tNC/V8X0CKXn4FEpmR2LSJeRRvVvKMDXOH9IWAGqEYCCyY9tIALrfOlZHSbRgHOaIqPm WeWyljfyHCv8gpRcPCZV5ImGaxPPJyqn8uSXCGLdjtXxtYRmprRbyyI+qBrAvmt8lqmg Qwyss28dCn8v2XA2KpRopKuaZuXDNde1+NZ+p6/slJ6Lluyf6LCArRlnwV0XKXMAPKrS Pong== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692900983; x=1693505783; 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=7V339yE8bPMm+KmAAdyGZ6ExwOtcmP76lDiycvZ+QhM=; b=PZhNNdhX7eht7hSj746RmNxf+jzm2Ondw3MBcTDIIWvuUQVmmbStp4i3H69YXAODcc C/e1HAwvbEU9jfjCPPigJcFsRoj2cfuomuvgvW0K9RYDWBxvowM2AbRsHiR3z3NQPC9e fPk9pG3JZMRl5sBYM1HNuAavAvEcLptuQS/LlXLR1psjCrJN3iyDTaLjmwtLoKD5tCuh dHsSrvpAsUMawQEQ2viVkuC/0LrUz7engkq1qFOgrKnLIspiAErKs8oPvEybOFMc8pgG Q9v+jpxkzN1qvo9BVSgicxjk5WTtUsRDaiChkGMoWvJjr4kv3epMQ2gabqoYVLLdMFiW YpJw== X-Gm-Message-State: AOJu0YxhGEitCpL0tHvQaBUePHFHfQgpIjpkKu+OrwJ67gRB/CR9Cf+s DVxKyTzyY0HQJCVqwQwzOKh6CBQbPXhRIZEDhgq5qw== X-Google-Smtp-Source: AGHT+IECNuJjCUDHAbVkXcrjqS3Bj6d3JaKHEw0JOGYScAGMdiPhJmizveJJgIi+tQXrkfH46aZeiQvAlOl6fbb4ins= X-Received: by 2002:a2e:6e0c:0:b0:2b9:ef0a:7d4b with SMTP id j12-20020a2e6e0c000000b002b9ef0a7d4bmr12177646ljc.31.1692900982999; Thu, 24 Aug 2023 11:16:22 -0700 (PDT) MIME-Version: 1.0 References: <20230821205458.1764662-1-yosryahmed@google.com> <20230821205458.1764662-4-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 24 Aug 2023 11:15:46 -0700 Message-ID: Subject: Re: [PATCH 3/3] mm: memcg: use non-unified stats flushing for userspace reads To: Michal Hocko Cc: Andrew Morton , Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , Ivan Babrou , Tejun Heo , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 1926BC002B X-Stat-Signature: 1ar9djsbmh9uwpsknyhqox8gdxjhhcqz X-Rspam-User: X-HE-Tag: 1692900984-395817 X-HE-Meta: U2FsdGVkX19DtSNhxMi11Ic59lvlb+oQwI8GQR7IKFsl7dJt4qzIYAco0mUAXKGAYseodkRFsyhLBQ28LYo27g2lvepzXFBEB5cOHuw43aKSS0VVXbCk6zqfJ8GViwmimw5O7Sj2a2X53hXwXaLm3pz3EyHrRqafEBscStnhMFX1Wv5xok6ntY3F/7xfir41V8DEgV+0YZNjLshyAjpfAf6x7D5l2EC8E3a3LNWPWfnjcKzPuJ3v7KdwXG2OszFSB2oZQgHLxl4iIl6MVKIZlMXCCIbfIOsyb+rn73WcSKIv1mjma+F+yyTdV1dhY17SfaIeRZ93jFWTAyQPm0rV+/9ov6yL1kyLtOQPBOmVhfK0GofLlVEUySOpFf5u3QN2LeB9/4tYMmv7JQGciWACjjmFObF1fm7VFkk617vvIJ4RQJIR3xGBpznNIesgUNCJiSUvdJCOsXczpmiTWZ4F3AjHK6bTpwxtubKoGUIsO6WOYGKvkZvZ4L6gB8EflQgvkwKICYD4vhXMy5dCuwerEzCyGjso4vEuVoM/VCCjMybeUjy9kAGvFpTZglCx+A6fb84W4w1XpTep+VCs97VzGsg3q4oHTH6D3IV4gN/PXs4UTybil8s3eYrF3x7gxX4Ox8dGG0iLSEMhKaVy20g2kebz5hHaGVaqAtiqGHgElXT8M7g5DxOKSlfIHRg5MGqsIG+S/fXw1Cqez+01MQK5iTtjI2K12EpjMfv1nrOEw0VbVaR3VyZMCt7kJrM+NIsCCveOqxiPORC4ItpIZDQENTORq3h9WrJzPs1q8I5s8C3QjavFzQbeJNt7MOkog93zMyhVEytRE/5bHQabjxT3d+QnH+bcU/XifYLOUjrLqCdPX/svQwOXr95wrfNPfLjZ4hFXB23nhRayhZSjk7x9PLT59Zzw/IX10diq2ZG37ulz2QIyHgfHsOjPD29BKd+rrreO5Hh0gbOrEWK7XYQ HwuBjm4N Lxf1dtubyTPFR79M7zaqNKiUyEOIqEq1KaxXvfmo40+LjUhyNIDiQxtsyfp1yT11Csixf29MmB0DxyCyrTuRFHyPw0CsW/eASus4bn8GO5ennNBY9a2cmxnnr2/0LuwpN0J/z8lyHQXVjChhRJOsYlpvkrX4Li9vssCTFG7hcbweOm80QNMpbaqRbfmJVqvg5plMjiko3knRbrHBUZrgVERwDX1SneOIjLSBKnX9iSH93Zufe2aptpbRDVJ/SEz7UJBVmeoM+svnliJXQVLv/rjopgGeR8/ZFQ02I 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 Thu, Aug 24, 2023 at 12:13=E2=80=AFAM Michal Hocko wro= te: > > On Wed 23-08-23 07:55:40, Yosry Ahmed wrote: > > On Wed, Aug 23, 2023 at 12:33=E2=80=AFAM Michal Hocko = wrote: > > > > > > On Tue 22-08-23 08:30:05, Yosry Ahmed wrote: > > > > On Tue, Aug 22, 2023 at 2:06=E2=80=AFAM Michal Hocko wrote: > > > > > > > > > > On Mon 21-08-23 20:54:58, Yosry Ahmed wrote: > > > [...] > > > > So to answer your question, I don't think a random user can really > > > > affect the system in a significant way by constantly flushing. In > > > > fact, in the test script (which I am now attaching, in case you're > > > > interested), there are hundreds of threads that are reading stats o= f > > > > different cgroups every 1s, and I don't see any negative effects on > > > > in-kernel flushers in this case (reclaimers). > > > > > > I suspect you have missed my point. > > > > I suspect you are right :) > > > > > > > Maybe I am just misunderstanding > > > the code but it seems to me that the lock dropping inside > > > cgroup_rstat_flush_locked effectivelly allows unbounded number of > > > contenders which is really dangerous when it is triggerable from the > > > userspace. The number of spinners at a moment is always bound by the > > > number CPUs but depending on timing many potential spinners might be > > > cond_rescheded and the worst time latency to complete can be really > > > high. Makes more sense? > > > > I think I understand better now. So basically because we might drop > > the lock and resched, there can be nr_cpus spinners + other spinners > > that are currently scheduled away, so these will need to wait to be > > scheduled and then start spinning on the lock. This may happen for one > > reader multiple times during its read, which is what can cause a high > > worst case latency. > > > > I hope I understood you correctly this time. Did I? > > Yes. I would just add that this could also influence the worst case > latency for a different reader - so an adversary user can stall others. I can add that for v2 to the commit log, thanks. > Exposing a shared global lock in uncontrolable way over generally > available user interface is not really a great idea IMHO. I think that's how it was always meant to be when it was designed. The global rstat lock has always existed and was always available to userspace readers. The memory controller took a different path at some point with unified flushing, but that was mainly because of high concurrency from in-kernel flushers, not because userspace readers caused a problem. Outside of memcg, the core cgroup code has always exercised this global lock when reading cpu.stat since rstat's introduction. I assume there hasn't been any problems since it's still there. I was hoping Tejun would confirm/deny this.