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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB914C433EF for ; Thu, 4 Nov 2021 21:27:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6AC6E61051 for ; Thu, 4 Nov 2021 21:27:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6AC6E61051 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id EE5A66B0071; Thu, 4 Nov 2021 17:27:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E947E6B0072; Thu, 4 Nov 2021 17:27:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5BAB940007; Thu, 4 Nov 2021 17:27:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0110.hostedemail.com [216.40.44.110]) by kanga.kvack.org (Postfix) with ESMTP id C2C5A6B0071 for ; Thu, 4 Nov 2021 17:27:55 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8179C6EDF3 for ; Thu, 4 Nov 2021 21:27:55 +0000 (UTC) X-FDA: 78772535310.12.442831F Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf30.hostedemail.com (Postfix) with ESMTP id 942C0E001982 for ; Thu, 4 Nov 2021 21:27:38 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id D14516120F; Thu, 4 Nov 2021 21:27:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1636061274; bh=i9bMCMWDq8qHtNLlg+d8d+bhz1QaRU5Lfr6G49bzhRs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=W49zmmuOtuvil1F/FB/CNc96Rs+frDTFSY/kBa0OMbA6zracevDH8JNrTJpvcMOLJ zvojXYCv8MRxejfqR2v9CDScI5Y2DFrHbUs1yDrF90ozZMDEr0IIqWVxkB4rapy9Xg GY7j0KWCbsCGMfp/9cLEdNiwLY4e+eYMvtWFt274= Date: Thu, 4 Nov 2021 14:27:51 -0700 From: Andrew Morton To: Shakeel Butt Cc: mkoutny@suse.com, cgroups@vger.kernel.org, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org Subject: Re: [PATCH v2 1/2] memcg: flush stats only if updated Message-Id: <20211104142751.5ab290d5cf4be1749c9c87ed@linux-foundation.org> In-Reply-To: <20211014163146.2177266-1-shakeelb@google.com> References: <20211013180130.GB22036@blackbody.suse.cz> <20211014163146.2177266-1-shakeelb@google.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=W49zmmuO; dmarc=none; spf=pass (imf30.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 942C0E001982 X-Stat-Signature: kmmh56upp73wd9r4h4go84jbapdmctnm X-HE-Tag: 1636061258-38533 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, 14 Oct 2021 09:31:46 -0700 Shakeel Butt wrote: > Hi Michal, >=20 > On Wed, Oct 13, 2021 at 11:01 AM Michal Koutn=FD wrote: > > > > On Fri, Oct 01, 2021 at 12:00:39PM -0700, Shakeel Butt wrote: > > > In this patch we kept the stats update codepath very minimal and let = the > > > stats reader side to flush the stats only when the updates are over a > > > specific threshold. =A0For now the threshold is (nr_cpus * CHARGE_BAT= CH). > > > > BTW, a noob question -- are the updates always single page sized? > > > > This is motivated by apples vs oranges comparison since the > > =A0 =A0 =A0 =A0 nr_cpus * MEMCG_CHARGE_BATCH > > suggests what could the expected error be in pages (bytes). But it's mo= stly > > wrong since: a) uncertain single-page updates, b) various counter > > updates summed together. I wonder whether the formula can serve to > > provide at least some (upper) estimate. > > >=20 > Thanks for your review. This forces me to think more on this because each > update does not necessarily be a single page sized update e.g. adding a h= ugepage > to an LRU. >=20 > Though I think the error is time bounded by 2 seconds but in those 2 seco= nds > mathematically the error can be large. Sounds significant? > What do you think of the following > change? It will bound the error better within the 2 seconds window. This didn't seem to go anywhere. I'll send "memcg: flush stats only if updated" Linuswards, but please remember to resurrect this idea soonish (this month?) if you think such a change is desirable.