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.1 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_AGENT_SANE_1, 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 17F52C433DF for ; Thu, 6 Aug 2020 16:41:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 47C32204FD for ; Thu, 6 Aug 2020 16:41:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="stM9mBca" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 47C32204FD 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 63C7F6B0005; Thu, 6 Aug 2020 12:41:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5EC7F6B0007; Thu, 6 Aug 2020 12:41:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E0A18D0001; Thu, 6 Aug 2020 12:41:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0003.hostedemail.com [216.40.44.3]) by kanga.kvack.org (Postfix) with ESMTP id 36AD66B0005 for ; Thu, 6 Aug 2020 12:41:24 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DF00D181AEF0B for ; Thu, 6 Aug 2020 16:41:23 +0000 (UTC) X-FDA: 77120709246.29.smell77_0e118b726fb9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id B97EF18086E39 for ; Thu, 6 Aug 2020 16:41:23 +0000 (UTC) X-HE-Tag: smell77_0e118b726fb9 X-Filterd-Recvd-Size: 7008 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Thu, 6 Aug 2020 16:41:23 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id v21so29381668otj.9 for ; Thu, 06 Aug 2020 09:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=vZCQg8+eOt4xV3JIQtSzWjGSCEAJBUaAw1bfGf3lBko=; b=stM9mBcaLLBoAVOGyLKRqBDV5bdXIlOzBVmFTAKYX50Mr5IQvi9vQ7AvJM0L4/5m2R 9codphlIh6NL4Pt3LU5mseL3yk8JTQm+BR8N4MYqDjO9mHJ8x6FOPMmjHNWkJbtr+2o6 +BzRU2mzFug8SMV4TeecXCGHUMQO0R83U9nQ0alj4hZQ9v64s/6H8sKcErGhz6qAWWcP 5cE0Qp9uaWTwsKWkCuUvwCe7ykJ3HslBcRjmn9wZaGw93/xGXswfiNLNMQURTHFjCkIK yBLhUJaqL8Xy/pBfMli9d7cYEDhUei8+y6rLgEeLpZ5u7q2zacbJN9TlUTh4SpSjFzoR L8Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=vZCQg8+eOt4xV3JIQtSzWjGSCEAJBUaAw1bfGf3lBko=; b=YMDcVNIBFaqfVzLUVY4AMzXdtSZHpGP+Z/WwdjDLAfQlGH+C+Mczu7UzyRkrlJ+xjN O9qOVQP6fc+8CfqAKiGr/InO6NJsKzBqpwKgBS3Hz9hHIc2EoPvpwUDaxIshcGletFL5 4XsF2eK/PxvsP3oamqdDC+XPqDbjHge9lxTcvZtTbTqGlvF7bragqbEdicDgIKTPpXk9 Cte+5DGR6ApbhoAhXFCIzetSErFrEBPuErijX4KD+s4IYwOoFjVWpm2n7PwH0/EdKKoc DK4xNnw/hWOZRdqGe1WAdwsHM+5ohUo+mp/gq8nBal2Sl6zjfiajzOiJ1ZcLz7HopzW9 XKag== X-Gm-Message-State: AOAM530mMj1aOp3CFqnQqSWRvbSCWSqMGJ4zdPrUr6WT8G5Y7tdRuk1A avktmz24h/4KNGrG6RRAZRxzoQ== X-Google-Smtp-Source: ABdhPJz602trHpkpOhs26Phasf2ch9/0QyldoGfsTVMlNz3IbhPyWBm6fFiVU4sXegQNDrqI9OAT4w== X-Received: by 2002:a9d:69cd:: with SMTP id v13mr7842427oto.64.1596732082316; Thu, 06 Aug 2020 09:41:22 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id z4sm1095537ota.52.2020.08.06.09.41.20 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 06 Aug 2020 09:41:21 -0700 (PDT) Date: Thu, 6 Aug 2020 09:41:05 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Roman Gushchin cc: Hugh Dickins , Andrew Morton , Johannes Weiner , Michal Hocko , Vlastimil Babka , linux-mm@kvack.org, kernel-team@fb.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: vmstat: fix /proc/sys/vm/stat_refresh generating false warnings In-Reply-To: <20200806035140.GA1162560@carbon.dhcp.thefacebook.com> Message-ID: References: <20200714173920.3319063-1-guro@fb.com> <20200730162348.GA679955@carbon.dhcp.thefacebook.com> <20200801011821.GA859734@carbon.dhcp.thefacebook.com> <20200804004012.GA1049259@carbon.dhcp.thefacebook.com> <20200806035140.GA1162560@carbon.dhcp.thefacebook.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Rspamd-Queue-Id: B97EF18086E39 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 Wed, 5 Aug 2020, Roman Gushchin wrote: > On Wed, Aug 05, 2020 at 08:01:33PM -0700, Hugh Dickins wrote: > > > > I shall certainly want to reintroduce those stats to checking for > > negatives, even if it's in a patch that never earns your approval, > > and just ends up kept internal for debugging. But equally certainly, > > I must not suddenly reintroduce that checking without gaining some > > experience of it (and perhaps getting as irritated as you by more > > transient negatives). > > > > I said earlier that I'd prefer you to rip out all that checking for > > negatives, rather than retaining it with the uselessly over-generous > > 125 * nr_cpus leeway. Please, Roman, would you send Andrew a patch > > doing that, to replace the patch in this thread? Or if you prefer, > > I can do so. > > Sure, I can do it. But can you, please, explain why you want them to be > eliminated? Is this because they will never fire, you think? Yes, I've never seen a machine on which vm/stat_refresh reported -16000 or less, or anything approaching that (true, this laptop does not have 128 cpus, but...). Maybe they get reinstalled or otherwise rebooted before reaching numbers of that magnitude. Maybe having the warnings shown at much lower magnitudes has helped to root-cause and eliminate some of them. Waiting until the heat-death-of-the-universe theoretical worst case is so unhelpful as to defeat the purpose of the warning. I think you do understand, but perhaps not all readers of this thread understand, that vm/stat_refresh merges all per-cpu counts into the global atomic immediately before deciding negative. The only problem is that "immediately" is not instantaneous across cpus, so the possibility of work started on one cpu but completed on another during the course of the refresh, causing false negatives, is real though not great. > > In my humble opinion they might be quite useful: any systematic under- or > overflow will eventually trigger this warning, and we'll know for sure that > something is wrong. So I'd add a similar check for node counters without > any hesitation. It's true that while developing, we can all make mistakes so big that "eventually" will show up quickly, and even that warning could help. But since you'll only show them when they reach -16000 (sorry, I keep going back to the 128 cpu case, just to make it more vivid), it won't be of any use to catch races later in development, or in production. Whereas my own patch would just fix the missing items, and continue to annoy you with occasional ignorable warnings - so I cannot submit that, and wouldn't want to submit it right now, without having tried it out for a while, to check what kind of noise it will generate. So I thought it best, either to leave mm/vmstat.c alone for the moment, or else just delete the disputed and incomplete code; coming back to it later when we have something we can agree upon. But I think you're preferring to resubmit your 125*nr_cpus patch to akpm, with the missing NR_VM_NODE_STAT_ITEMS added in (as either one or two patches), with foreshortened testing but the reassurance that since it's so hard to reach the point of showing the warnings, new negatives will either be quiet, or easily fixed before v5.10 released: okay, I can more easily Hack that to my preference than Ack it or Nak it. Hugh