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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 C3534C433ED for ; Wed, 14 Apr 2021 12:56:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 21AFE611AD for ; Wed, 14 Apr 2021 12:56:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 21AFE611AD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 59C356B008C; Wed, 14 Apr 2021 08:56:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 54FE06B0093; Wed, 14 Apr 2021 08:56:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39F7A8D0001; Wed, 14 Apr 2021 08:56:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0002.hostedemail.com [216.40.44.2]) by kanga.kvack.org (Postfix) with ESMTP id 18F2F6B008C for ; Wed, 14 Apr 2021 08:56:48 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CE5FA1814B0E8 for ; Wed, 14 Apr 2021 12:56:47 +0000 (UTC) X-FDA: 78030972054.15.C3EF3A0 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf13.hostedemail.com (Postfix) with ESMTP id 4A1FAE000114 for ; Wed, 14 Apr 2021 12:56:44 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 4F0B1AFC8; Wed, 14 Apr 2021 12:56:46 +0000 (UTC) To: Mel Gorman , Linux-MM , Linux-RT-Users Cc: LKML , Chuck Lever , Jesper Dangaard Brouer , Matthew Wilcox , Thomas Gleixner , Peter Zijlstra , Ingo Molnar , Michal Hocko , Oscar Salvador References: <20210407202423.16022-1-mgorman@techsingularity.net> <20210407202423.16022-5-mgorman@techsingularity.net> From: Vlastimil Babka Subject: Re: [PATCH 04/11] mm/vmstat: Convert NUMA statistics to basic NUMA counters Message-ID: <7a7ec563-0519-a850-563a-9680a7bd00d3@suse.cz> Date: Wed, 14 Apr 2021 14:56:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210407202423.16022-5-mgorman@techsingularity.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4A1FAE000114 X-Stat-Signature: jom9f5a5dwujqejp45esedt8u1bmw5yx Received-SPF: none (suse.cz>: No applicable sender policy available) receiver=imf13; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1618405004-941579 Content-Transfer-Encoding: quoted-printable 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 4/7/21 10:24 PM, Mel Gorman wrote: > NUMA statistics are maintained on the zone level for hits, misses, fore= ign > etc but nothing relies on them being perfectly accurate for functional > correctness. The counters are used by userspace to get a general overvi= ew > of a workloads NUMA behaviour but the page allocator incurs a high cost= to > maintain perfect accuracy similar to what is required for a vmstat like > NR_FREE_PAGES. There even is a sysctl vm.numa_stat to allow userspace t= o > turn off the collection of NUMA statistics like NUMA_HIT. >=20 > This patch converts NUMA_HIT and friends to be NUMA events with similar > accuracy to VM events. There is a possibility that slight errors will b= e > introduced but the overall trend as seen by userspace will be similar. > Note that while these counters could be maintained at the node level th= at > it would have a user-visible impact. I guess this kind of inaccuracy is fine. I just don't like much fold_vm_zone_numa_events() which seems to calculate sums of percpu counte= rs and then assign the result to zone counters for immediate consumption, which = differs from other kinds of folds in vmstat that reset the percpu counters to 0 a= s they are treated as diffs to the global counters. So it seems that this intermediate assignment to zone counters (using atomic_long_set() even) is unnecessary and this could mimic sum_vm_events= () that just does the summation on a local array? And probably a bit more serious is that vm_events have vm_events_fold_cpu= () to deal with a cpu going away, but after your patch the stats counted on a c= pu just disapepar from the sums as it goes offline as there's no such thing for t= he numa counters. Thanks, Vlastimil