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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08C27C48BE8 for ; Tue, 15 Jun 2021 21:52:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 855A96128B for ; Tue, 15 Jun 2021 21:52:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 855A96128B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EDCBC6B006C; Tue, 15 Jun 2021 17:52:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E8BBC6B006E; Tue, 15 Jun 2021 17:52:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D049A6B0070; Tue, 15 Jun 2021 17:52:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0111.hostedemail.com [216.40.44.111]) by kanga.kvack.org (Postfix) with ESMTP id 9E7E86B006C for ; Tue, 15 Jun 2021 17:52:50 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 345C0362B for ; Tue, 15 Jun 2021 21:52:50 +0000 (UTC) X-FDA: 78257308500.10.06E8E62 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf22.hostedemail.com (Postfix) with ESMTP id B99DFC001C7C for ; Tue, 15 Jun 2021 21:52:39 +0000 (UTC) Received: by mail-lj1-f182.google.com with SMTP id x14so764360ljp.7 for ; Tue, 15 Jun 2021 14:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0XQnzVjTuP7aBILPyoyVQYQXqE/KQql4/BGG/kkVsjE=; b=gGfsNADVzHheLJtshFSvaD/DGD7MMjGpXn9cuW+cqCUX2Xd2zmn5p3v+yDXFjhYjtK PDLnOr1KKcT1OLCV6DmMntBGhrfUy0fxFML9PTdLQwix8Sd1hhPKRkJq6T0G7E4Ih+NA bygB5L8TqSiTWvrpf2PeCWl4nP29lwEvs0p8hAUMjE225soFkN2+WNABhSNuB+euV8Q/ HSj4o5EqiwXTsqhpK8SRG3q2fz0JovM5ppq9RUlGel+tygTg+OEql0sia8kFjIp7n0lC rSEFJnNMUDNnbVoVZyuQrRWa9O1SgCOtrk9ljun/mmLILGGgE16kacXSjSAUEPM4K2jZ iBoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0XQnzVjTuP7aBILPyoyVQYQXqE/KQql4/BGG/kkVsjE=; b=k4ov9KDmbpRyzvUSaZG0ITWnhrt5fZHzHKqmqoCRufukhPgr+mUS+VjaXWmVaY/e4B IjY03Bg2GX9VxSZe+nq546bUa5A6s50rEdym7f0hx7ZG/F/YH/ppLcyi2990KKTfq2XW aO0KBTfTr1Jn6J7c2jN8PWMEkU93QjYygzwJeelS4c4/Y/GXw5jNJ5zPnsPuaXtWjrdJ JXq1Q1r/XIqlJ/sewL5dwoRzevQQnpWIQ2f1F6WfTOHf6IqG/WCDq+mzcN9T+CNyeQ21 Y8iDutsJ1HTNbuuWMsUKH0pFwKBdiDdKxkHk4BihbyPt/Lt4X/vu5nKWmBLUYOyBaCcl LAAA== X-Gm-Message-State: AOAM530VTT0A6kFJoRDI5z6QfMD+I7JKpAjIBwHakiO3zJSLlbln7/zd dkysp6jxVxwexC12E44h9uyFRRzDVKsylG2lGpSvPw== X-Google-Smtp-Source: ABdhPJwJu/tvSMtLHSaZgYb0ugWasxEscMYkOfpr1bpGAqWcyf39Efy4gbX1yv+dRzvE6RNhfOZX1SkRbib2UJyn5IE= X-Received: by 2002:a05:651c:3c6:: with SMTP id f6mr1450704ljp.456.1623793968085; Tue, 15 Jun 2021 14:52:48 -0700 (PDT) MIME-Version: 1.0 References: <20210615174435.4174364-1-shakeelb@google.com> <20210615174435.4174364-2-shakeelb@google.com> In-Reply-To: From: Shakeel Butt Date: Tue, 15 Jun 2021 14:52:37 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] memcg: periodically flush the memcg stats To: Johannes Weiner Cc: Tejun Heo , Muchun Song , Michal Hocko , Roman Gushchin , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Huang Ying , Andrew Morton , Cgroups , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B99DFC001C7C X-Stat-Signature: 4m73rthenya84hd36dpg8gzgez8iayx6 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=gGfsNADV; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of shakeelb@google.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=shakeelb@google.com X-HE-Tag: 1623793959-172978 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 Tue, Jun 15, 2021 at 12:29 PM Johannes Weiner wrote: > > Hey Shakeel, > > On Tue, Jun 15, 2021 at 10:44:35AM -0700, Shakeel Butt wrote: > > At the moment memcg stats are read in four contexts: > > > > 1. memcg stat user interfaces > > 2. dirty throttling > > 3. page fault > > 4. memory reclaim > > > > Currently the kernel flushes the stats for first two cases. Flushing the > > stats for remaining two casese may have performance impact. Always > > flushing the memcg stats on the page fault code path may negatively > > impacts the performance of the applications. In addition flushing in the > > memory reclaim code path, though treated as slowpath, can become the > > source of contention for the global lock taken for stat flushing because > > when system or memcg is under memory pressure, many tasks may enter the > > reclaim path. > > > > Instead of synchronously flushing the stats, this patch adds support of > > asynchronous periodic flushing of the memcg stats. For now the flushing > > period is hardcoded to 2*HZ but that can be changed later through maybe > > sysctl if need arise. > > I'm concerned that quite a lot can happen in terms of reclaim and page > faults in 2 seconds. It's conceivable that the error of a fixed 2s > flush can actually exceed the error of a fixed percpu batch size. > Yes, that is possible. > The way the global vmstat implementation manages error is doing both: > ratelimiting and timelimiting. It uses percpu batching to limit the > error when it gets busy, and periodic flushing to limit the length of > time consumers of those stats could be stuck trying to reach a state > that the batching would otherwise prevent from being reflected. > > Maybe we can use a combination of ratelimiting and timelimiting too? > > We shouldn't flush on every fault, but what about a percpu ratelimit > that would at least bound the error to NR_CPU instead of nr_cgroups? > Couple questions here: First, to convert the error bound to NR_CPU from nr_cgroups, I think we have to move from (delta > threshold) comparison to (num_update_events > threshold). Previously an increment event followed by decrement would keep the delta to 0 (or same) but after this change num_update_events would be 2. Is that ok? Second, do we want to synchronously flush the stats when we cross the threshold on update or asynchronously by queuing the flush with zero delay? > For thundering herds during reclaim: as long as they all tried to > flush from the root, only one of them would actually need to do the > work, and we could use trylock. If the lock is already taken, you can > move on knowing that somebody is already doing the shared flush work. Yes, this makes sense.