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 6427EC63797 for ; Tue, 17 Jan 2023 12:52:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E0A746B0074; Tue, 17 Jan 2023 07:52:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DBA076B0075; Tue, 17 Jan 2023 07:52:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA8E76B0078; Tue, 17 Jan 2023 07:52:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B88A06B0074 for ; Tue, 17 Jan 2023 07:52:22 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8CC94160912 for ; Tue, 17 Jan 2023 12:52:22 +0000 (UTC) X-FDA: 80364279324.20.EF95361 Received: from gentwo.de (gentwo.de [161.97.139.209]) by imf30.hostedemail.com (Postfix) with ESMTP id 8733B80011 for ; Tue, 17 Jan 2023 12:52:20 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gentwo.de header.s=default header.b=UWEiNtKG; dmarc=pass (policy=none) header.from=gentwo.de; spf=pass (imf30.hostedemail.com: domain of cl@gentwo.de designates 161.97.139.209 as permitted sender) smtp.mailfrom=cl@gentwo.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673959941; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4MtLJkkrXsyIiXO9P2qd65mct+kptfukKvKG/JQ7WaE=; b=OKCniYWOEtWz56iMXaaE7VC1BS2pA63kODHCdDGJjel+Z0TJwQoaX1R7HYWdaKXDfiEeSj R8qeK5s6OLLFFqqZ60k4gkbFOVxIuvBBW654EdmePIn2eMe9ikpOMAooH2VOetgTCKYotF WEqY8TjShVuQmJJEhs+E+OnLrtpbW/g= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gentwo.de header.s=default header.b=UWEiNtKG; dmarc=pass (policy=none) header.from=gentwo.de; spf=pass (imf30.hostedemail.com: domain of cl@gentwo.de designates 161.97.139.209 as permitted sender) smtp.mailfrom=cl@gentwo.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673959941; a=rsa-sha256; cv=none; b=Fky4w05gNFnXBAm2CqxuOMyhAMTlsS2URdNAdBoLX7IedaxUCrq8iD8S46ICqLAbHZyn/a uzFAfBmTrNRXBZnMOqadsJtTWSuNzTnh48JXgfZ+NRG2Uy5HeOa61BoEBcUpj1/nUY2KiH VaZ56pqpDKzMfOwoFglG+ZxRyrbjURs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.de; s=default; t=1673959938; bh=eyH74BJ/7IIhmnPK8RsGXK4MMB69Q2QKmBRINALqzMY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=UWEiNtKGqkIkX65IVF64nS/tHSIZ8csoAumnpxSMXk+x2SORolGIWPGf4CtdeHGW8 HTpgLOvKHTMhdicuvoG4bCT5Y6RRUAp4VkpNYTyeMVJMCXXJHsmDcafWPfqryT5Qip PG+wi1odCf/m17w1HSEHKrYBlvdj/ipk3XggrRAQJThC6c3reiAcTOQv36S7iT0H4O VKR9Lp8jmeOSNi/ZfJvoTkCuHt0puTSfjv/Cj8x13xUiG/UhT+drCzs89lyrb05WkH MhL9tYO3w/OLBADl0pB9G+lGwZ/UBc0rn5EcshX9eOKmamU5inxzERgHWzUj47FSln leGVVBTwIFYqA== Received: by gentwo.de (Postfix, from userid 1001) id 2B777B0023C; Tue, 17 Jan 2023 13:52:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by gentwo.de (Postfix) with ESMTP id 286F0B000FF; Tue, 17 Jan 2023 13:52:18 +0100 (CET) Date: Tue, 17 Jan 2023 13:52:18 +0100 (CET) From: Christoph Lameter To: Marcelo Tosatti cc: Frederic Weisbecker , atomlin@atomlin.com, tglx@linutronix.de, mingo@kernel.org, peterz@infradead.org, pauld@redhat.com, neelx@redhat.com, oleksandr@natalenko.name, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v13 2/6] mm/vmstat: Use vmstat_dirty to track CPU-specific vmstat discrepancies In-Reply-To: Message-ID: <74e4afd4-5695-90fb-e66e-25d2bc2e2f53@gentwo.de> References: <20230105125218.031928326@redhat.com> <20230105125248.813825852@redhat.com> <7c2af941-42a9-a59b-6a20-b331a4934a3@gentwo.de> <60183179-3a28-6bf9-a6ab-8a8976f283d@gentwo.de> <24ca2aad-54b2-2c3a-70b5-49a33c9a33@gentwo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 8733B80011 X-Stat-Signature: n1dabedzi6dzzw4ern7undu3tudobtkw X-HE-Tag: 1673959940-9900 X-HE-Meta: U2FsdGVkX199MCIz8a6BpwXOK94g+DMK9aLheOhetFc0RJx03V4UzQxDBGdNN5Cl1BetKCbh2nRRSdNGfxKy35LeQZrqZVxtDsGeZlsUbQDHUq02kVJWB4mpA7Lk892kkJWuo6ZuQhexecTWQWjmhaaBEwy6mkyjwH48MZYn/NNRwwX0GJUlGYiGelvf2uHHPSChOiGS67GD2qFC/uKWeU8qKqzr3e2nElsb9c9vZ/65yXbcWePzSeTrHzROCzTplQahZpRvSmJQShe2mkKoRl1Q4mgt3YIjDw3xrg/SjaQFNzc59/OsbXmUktdJrAgm9m686JDzKzUFBd5JMglGL1yk75aQEknjYdypmtQip588euFydDOjjoTmraG4lPkLjYQjhTC3s2ZNCJWUkwUQTeIeM156NEDxBCQSQv57FSvveOV4UAajxZxrLFLgKIiRsGp/uvckcvvp61aZ+tAC5JkG6bMyEBNrm1+jDNwQ5TkNllRIldHBgQopwRs2dqyVbEXb+PE32tH1coew52Jo7JKhm7LSiaJK/4+wPiEZvChtyakpj6CJYeBS5AqMD3jMQY5zjN11x4zhoNsHyFAJUhR43/Rpp/rrtT+EyouVNdkEDN2o0pBr6K41t1BxJtioEPsvZpP6KtmjtKwkwAscJl2xx50FH6k6/OzUGD5BqQUQ2vwNl2UI3M2alMqLeawT0mJynaGhBDOOEixcjetMk56MnfMpYkPs+Dm2d8WHHV0xljN/yX0Mp9UUTKEsLa3QiZ/Vp0Riczdtz5siqqhyEOp4F6oZKOamL6F0SHSr9cgkGDNSG96FfYkfaWGUAs6AKI0skEPfm09gU4PrDnZT5VGw4AO+tefw/tg6eYArzWeLlcmtTJoOBBAWbljh2oeC6N00HxLVO7BwhOj4F5ptkg== 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 Mon, 16 Jan 2023, Marcelo Tosatti wrote: > Honestly, to me, there is no dilemma: > > * There is a requirement from applications to be uninterrupted > by operating system activities. Examples include radio access > network software, software defined PLCs for industrial automation (1). > > * There exists vm-statistics counters (which count > the number of pages on different states, for example, number of > free pages, locked pages, pages under writeback, pagetable pages, > file pages, etc). > To reduce number of accesses to the global counters, each CPU maintains > its own delta relative to the global VM counters > (which can be cached in the local processor cache, therefore fast). The counters only count accurately as a global sum. A counter may be specific to a zone and at which time it counts uses of that zone of from all processors. > Now you are objecting to this patchset because: > > It increases the number of cycles to execute the function to modify > the counters by 6. Can you mention any benchmark where this > increase is significant? I am objecting because of a fundamental misunderstanding of how these counters work and because the patchset is incorrect in the way it handles these counters. Come up with a correct approach and then we can consider regressions and/or improvements in performance. > Alternatives: > 1) Disable periodic synchronization for nohz_full CPUs. > 2) Processor instructions which can modify more than > one address in memory. > 3) Synchronize the per-CPU stats remotely (which > increases per-CPU and per-node accesses). Or remove the assumptions that may exist in current code that a delta on a specific cpu counter means that something occurred on that cpu? If there is a delta then that *does not* mean that there is something to do on that processor. The delta could be folded by another processor into the global counter if that processor is idle or not entering the Kernel and stays that way throughout the operation. So I guess that would be #3. The function cpu_vm_stats_fold() already does this for offline cpus. Can something similar be made to work for idle cpus or those continually running in user space?