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 CA701C0032E for ; Wed, 25 Oct 2023 17:06:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38C136B034C; Wed, 25 Oct 2023 13:06:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33DBE6B034D; Wed, 25 Oct 2023 13:06:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2037C6B034E; Wed, 25 Oct 2023 13:06:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 155506B034C for ; Wed, 25 Oct 2023 13:06:53 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DEAB91A0255 for ; Wed, 25 Oct 2023 17:06:52 +0000 (UTC) X-FDA: 81384613464.07.D30B6FE Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf14.hostedemail.com (Postfix) with ESMTP id 22F9C100033 for ; Wed, 25 Oct 2023 17:06:50 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=oWNjdrJD; spf=pass (imf14.hostedemail.com: domain of shakeelb@google.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=shakeelb@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=1698253611; 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=0BLyhOS6DaA3Azb/y3i+aSNsSqvELymfgVFVzC4E2iU=; b=yiRuThqWYu/nwcKYSlUdvmhdVjvovhBzICtwi/NL/A3BF/HaD5217LgWUB7Jlt9gs7DYS/ IKmMStG7gGndSyezHSiw2bE1pQK5KjtzvP469ouReULkv22RQn7Tb+P/nBtm+5sOg1ROs8 iokOtiwYQ5d3yktP6ISVAQpSiIJt7d0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698253611; a=rsa-sha256; cv=none; b=VH+Y+4X+pZBQBZle9tso2drSG1ZEK488e6ivTs2gv1BmjkuzvFNzkmqTdFGaP6Y2Zlgb35 WCgL/ODvUTghZiJaZ8KR0i3ErmqIzyJkvGKke6FMNzWF6KzaXl4Ej37Q96lg4W/r78tSD+ M2qpnF9s1qTCKxGUGkPq+8sDypahud4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=oWNjdrJD; spf=pass (imf14.hostedemail.com: domain of shakeelb@google.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1c9c145bb5bso5075ad.1 for ; Wed, 25 Oct 2023 10:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698253610; x=1698858410; darn=kvack.org; 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=0BLyhOS6DaA3Azb/y3i+aSNsSqvELymfgVFVzC4E2iU=; b=oWNjdrJDfvjjgjmecrZZrM9EikGPTD+hcC2I54yeusH3ipXXzCbM1dpl+oz4foINPK F6f7DnEs0oebi527o+K7BMfcakab4mxRPl+qxTKkyRBt9S80Dz23LLO+eWf/0KmrN0pq HiP+kj79c+HUrmi7njAZodZA4kddeGACSwJ7v1b4WmcrKYR2TZsAC4Wgp1dfs9gCjad9 TixVYE6x4S7cQTB+ZSV4g6bt/7SZvLs1DVqugZ2InxhcwsTbtWnf2AStF0j1eDy/wZOe gCOJTzDwQGeRvEpv7+geo8d3hqmrzYiZm/6opkJCoBzWE3TukbSmtWd1gBvHEpE7QgfN K3yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698253610; x=1698858410; 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=0BLyhOS6DaA3Azb/y3i+aSNsSqvELymfgVFVzC4E2iU=; b=MLylkDfrIEM6PrzMeOh8tHZQEkkCVt9GWWxZbip1TGz/CyHBmdTQwgc8rkHco9qk8y nf6PoBAAfGMGh9vV9IpZGvtBD5JlGPK3XoQNks+9and/F0GTCucKbj7HiHM013ehhkrr H3uF3BvQIiS51RaPk80DOGTUb4/Gvw2Rwm6o+Q7TUU3ThFTlK3i2V/6F2EpMvSuFEoo6 v2Jz/PEp8WeAonTMo88nrNzi0lvF75DH2nNuN1pmFNXL80P0Yv1miku6nCY6N1eAbJbm 5hAMHjQKaTmkk2nlcFDeHmY0tbNUqdACjTSvFgUdTUPHhf3zdrEMgs0Wn4I+cS5lZ/mH r1fw== X-Gm-Message-State: AOJu0YyEQW16yCaMEbfeZmxrgJiNW5/savgzcg/rTNUX2gONUzzAicls XBDVUlXzDIB3jurNJhgfaUW0tsum4BpJudgl5Rt9kA== X-Google-Smtp-Source: AGHT+IHTm3Fl1nDGBKuyZQng/G9O2lKwSEtDCNTvLWku+yOpMLnEMFF3diKUa2ikj5TXXEN2m6Iuk1tLQYL8Awlf64s= X-Received: by 2002:a17:903:144b:b0:1ca:42a:1773 with SMTP id lq11-20020a170903144b00b001ca042a1773mr241841plb.12.1698253609714; Wed, 25 Oct 2023 10:06:49 -0700 (PDT) MIME-Version: 1.0 References: <20231010032117.1577496-4-yosryahmed@google.com> <202310202303.c68e7639-oliver.sang@intel.com> In-Reply-To: From: Shakeel Butt Date: Wed, 25 Oct 2023 10:06:37 -0700 Message-ID: Subject: Re: [PATCH v2 3/5] mm: memcg: make stats flushing threshold per-memcg To: Yosry Ahmed Cc: Oliver Sang , Johannes Weiner , Feng Tang , "oe-lkp@lists.linux.dev" , lkp , "cgroups@vger.kernel.org" , "linux-mm@kvack.org" , "Huang, Ying" , "Yin, Fengwei" , Andrew Morton , Michal Hocko , Roman Gushchin , Muchun Song , Ivan Babrou , Tejun Heo , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Waiman Long , "kernel-team@cloudflare.com" , Wei Xu , Greg Thelen , "linux-kernel@vger.kernel.org" , Domenico Cerasuolo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: nfzsd9ayo39oanjyauh6ia5i9n1xiswp X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 22F9C100033 X-Rspam-User: X-HE-Tag: 1698253610-56376 X-HE-Meta: U2FsdGVkX19lGZj6GElIv2ukdj+xY8ZaZQjUzfskDnuTmFei/Gzj4gIQphFGlDa2vZir7fE2c1J3zABlRu42gerAuQFgwOXS+DnXlUqnSYm2QWMdEaSq0siXa0rybR0ygqWB8YoHtux1OZoiXwHZO8+qh3l3wi5JaegAU59GV7L8xB7nKEuaqNJYfq+rL5wNpgANoC+Pm8eLkDC4jMzWAkL4aQdVB+mzywce9+TeyhS3baiazfxRBzlyElpb8uhfzToJJhTLatol1mw51z20mbatMOkEJzRw+ShW8pA+C3kZLp2H7S0u1zdK3pD1Dh2bld1xJKIlTBJHtnpQMKD6GYlZLGw8Il/2Ipau1nmAOZ4WRXqH8R1AiWAQQcCeAg693PayPo9E5SfSaduBbdG3VaYMcyQMFsjZf8offpf/4YSMTnhwM9LJ/2ZTG7K2jw0nxEtl0SPFQoX2mHhjDED8lLThqR2e+9z61G/ubuYdalOPcJ1txOJdRdOBRL/VokCEna9WZDRI6wI/iEH8LGtSNNlGGx/gYL6ww+QDJHHkDFgs/4YTnk0HFz0rQJBTXuhHQ/gKGvlgK87fyim961PixZd/jccy2i7Qfyt3PDLfz2PM8/LnrgEqc1r0Vm0TwhTs7QhhcUVZK30yR8Uf1lh8M5beH/uVJBQxqka+kq+WvuO5C1uMKCfZrGX8zmFjgXLpxJH6d5F0XZ8l83aCcn8TFEDxIuvncT0f6dJJvgdnz3MbYuItGxsn20NHV5JMzd4cy/VCndQK+2/KrtC807/MVqlZa/EA7+4NJJ7jT8UIenhpSc/eU7zJKaDsxxrIlZsbsVwCqkz/50cfmDLHLW6yBbiAPTsLaj0uGx4nvu2JWkgZ5oGx7b+2BR1BwUf6ohyK+5tXKcoz/wZiXBQr20lFuieu2oF9Wnl5jchlLLiIClmiQ663xMvmA2kojzXDxX//LJgU9GmYEVgy/Bn9IEM 9+T4XWEZ i5ymKZ+wOjygt8iP9P6oDhMFJ6V0DRLKvsRWrvyJ+K6E/T6IX+8pnUkqSJdf5pkOsBFUcegi58mUJLUW4mlSELIjgb4wR2sQilS0jUmCaqZ9vT0BJhpNrRwfuJSCzxWYedfyBheoNnWzIkfjmFT3mbh5l0zkH/8C3xP7wTt6AogwtNyoDto6beYDCCu9YuXHshGxppotyyVOn8zp/44IxV38YvPz8e4c3NwEbCqZe8M1Ibr30tXazMz0qPtssTMwShSp4kxsXtx7vt+I5Tm/+jN7U5d/mPIQjz64v/nbQDBvKksT9szSfZRX+WBoYE8VTit6wwLL0UkR4TcCyzoWqeTGPGtVcazT34xGMMEEAtXWfUALmkADOPaY9nA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000017, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Oct 24, 2023 at 11:23=E2=80=AFPM Yosry Ahmed wrote: > [...] > > Thanks Oliver for running the numbers. If I understand correctly the > will-it-scale.fallocate1 microbenchmark is the only one showing > significant regression here, is this correct? > > In my runs, other more representative microbenchmarks benchmarks like > netperf and will-it-scale.page_fault* show minimal regression. I would > expect practical workloads to have high concurrency of page faults or > networking, but maybe not fallocate/ftruncate. > > Oliver, in your experience, how often does such a regression in such a > microbenchmark translate to a real regression that people care about? > (or how often do people dismiss it?) > > I tried optimizing this further for the fallocate/ftruncate case but > without luck. I even tried moving stats_updates into cgroup core > (struct cgroup_rstat_cpu) to reuse the existing loop in > cgroup_rstat_updated() -- but it somehow made it worse. > > On the other hand, we do have some machines in production running this > series together with a previous optimization for non-hierarchical > stats [1] on an older kernel, and we do see significant reduction in > cpu time spent on reading the stats. Domenico did a similar experiment > with only this series and reported similar results [2]. > > Shakeel, Johannes, (and other memcg folks), I personally think the > benefits here outweigh a regression in this particular benchmark, but > I am obviously biased. What do you think? > > [1]https://lore.kernel.org/lkml/20230726153223.821757-2-yosryahmed@google= .com/ > [2]https://lore.kernel.org/lkml/CAFYChMv_kv_KXOMRkrmTN-7MrfgBHMcK3YXv0dPY= EL7nK77e2A@mail.gmail.com/ I still am not convinced of the benefits outweighing the regression but I would not block this. So, let's do this, skip this open window, get the patch series reviewed and hopefully we can work together on fixing that regression and we can make an informed decision of accepting the regression for this series for the next cycle.