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 B795CC678D4 for ; Thu, 2 Mar 2023 14:48:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 397BC6B0073; Thu, 2 Mar 2023 09:48:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 385306B0071; Thu, 2 Mar 2023 09:48:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 226F66B0075; Thu, 2 Mar 2023 09:48:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0CE396B0071 for ; Thu, 2 Mar 2023 09:48:52 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D09DDAAB4C for ; Thu, 2 Mar 2023 14:48:51 +0000 (UTC) X-FDA: 80524240062.09.76443CB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf27.hostedemail.com (Postfix) with ESMTP id E116140009 for ; Thu, 2 Mar 2023 14:48:49 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bludt38J; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf27.hostedemail.com: domain of mtosatti@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=mtosatti@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677768529; 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=MS5VgBYAjiu1GtS1Hz9hknenkB/L3zfoqR0xXE1AVFY=; b=trZIyebRcttPE54i9zXwyZFpzaF3RtUaAojUBwjK0tdfV6CLbuuz1REXrdEYKHXrt8HiAR s3KUtfW35k1x0uSiPMaVyWXcNsGz9POVG/UInc9j1Wcsvm4MKY7yNqIHZ9/qJPud299NUe 0k5yQdr4w4+OsMvdMQYMfjKBtngBBCM= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bludt38J; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf27.hostedemail.com: domain of mtosatti@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=mtosatti@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677768529; a=rsa-sha256; cv=none; b=vpjbvudTQAg8SDcqrUh+HoW/VG52aM2PMC2lLVIWaCXwYJ8Qj6xG/hAeG5ppC5lXGH9OQt 82KO1bhvGAY0XHGhLbY/QPpOCn2UjRsyOUaOsAQhEGUegyhPdt8HHZIW6Rxff4ZpBKIpx3 A8ZmM4N4s1JGQkgtw/G3O1PzvODwda8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677768529; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MS5VgBYAjiu1GtS1Hz9hknenkB/L3zfoqR0xXE1AVFY=; b=bludt38Jaq+J/OfTGwpmORIAKSAwnht9v+J+5UUT6eKmW39QN+r6qmT44QroaEGJdIFQO5 h++wZM4rVKocrqiPkFyA6QzQcho/PPXXuMQmmC73su0neA0beTFuNq+f/31+pg9GxJOain +/DLoHCO943i/pRaTPQO8tKOnyd6L0U= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-199-CcJVn-9SM7eNka9q6e28rA-1; Thu, 02 Mar 2023 09:48:48 -0500 X-MC-Unique: CcJVn-9SM7eNka9q6e28rA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6A43F2800490; Thu, 2 Mar 2023 14:48:47 +0000 (UTC) Received: from tpad.localdomain (ovpn-112-2.gru2.redhat.com [10.97.112.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2E2931121315; Thu, 2 Mar 2023 14:48:47 +0000 (UTC) Received: by tpad.localdomain (Postfix, from userid 1000) id 6C139400E71AF; Thu, 2 Mar 2023 10:55:09 -0300 (-03) Date: Thu, 2 Mar 2023 10:55:09 -0300 From: Marcelo Tosatti To: Peter Xu Cc: Christoph Lameter , Aaron Tomlin , Frederic Weisbecker , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 09/11] mm/vmstat: use cmpxchg loop in cpu_vm_stats_fold Message-ID: References: <20230209150150.380060673@redhat.com> <20230209153204.873999366@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E116140009 X-Stat-Signature: 7xawnb7kgmj9qfqnr4yqekfkd6uh8ix9 X-HE-Tag: 1677768529-337723 X-HE-Meta: U2FsdGVkX18Zs0GnBwkMqSQAgOr9Hl0MX1FKPuVy9tGFki+ke3Ro0fLmoHorxQEgKDM4uKck4IN16yvrpKErGnZo7hqXYGq87sF7DOj6UAOzwsin23UUKehrVyLT3k36+4a0jPaESLdp0G1RW/CQ+fRAGy5jekE1mKTtl6k7UXraEKSuAVcyl5+Asl5agKc6fxawn0vSMZ9Ws0BNUHU8M5bmHMCQ/QZ1MukerxxEsuzYzcI41CKHSYrp5yF6ypNnfKybRXi222pLXhuPNIi/ys8xucWa8s6OoKByX5k6UhbGpNGze4bpr6024OwE7Y36GYBdGMs4fhGqM88PSg5lAuVt8xa7vab/rUTfMt5WzLAmRkkTPJfGC8BSZyic28SPRSipxHZVqJ1R7jaTftsAD4J7E5JFuyttnieF74uz5FO4ev/FjyuCv0t9Lg9AkuJEeFPIJP3cmquUizuLpjvMwQX4ES1Zp4IO1fnlXGH4LlXuGoMydwcxqFf1zV2f0MFlgwJK1zH6GGea7dkAFRAIuo0oRTBogv/qyLG4qEa3WIxEGF1niskaSOjgcGxIqcMlB4DxeJkTc3XgdJsxgKqmOwjeC5xDL1ipxShrQyodVKM6NXIwNpIQGWsC30K0gLojDIYSfvcF9w3BsP0lMxbkeLidXr2kqxPIgAPl4iWG7B9V8DbuQmkh+5qWYjKgPiLKkKluSzsap5OUiDPS/2HmZNY7mV94v1oOUbYTWkzSF9lBzSqcCxzgfzxV6sD/1xpOgdSjNHj66l5G0uyoY8N6t8kxyu5pTLc/zH2RH6eKzwm1N5DoFhmWzp89OERSxNJrReL6fpj4flvaUSWoKrhTn0cJvfKNGUwhU6QZRDXGUiK8JdBipI/LhfTcjaAw32jJy+1TuSv0MW+lHXMWcw6c9L9imIuTsWynF3dLQfsCv7vxNn9EoGjBKQmYSvdRMN9D/j4dZZDEv9WdtlmjBo2 fc1cgVWO NkcwiUQbhXGHF9U/TEg1Vd7EgZ0xeAqdUFUea26tH5bMREzwEN83XB0ERXyVwhhE8954HcTpVeryLib4OL6ynN4ugIQ4v3rosw20dCIdjuQrDu81jqNIHlW2bn9dhG6Ax98j6Vfv5nMG1jw0TNCEs2RYTcToLe8M3ek554qqgnIWIwEuK2y9/gXaoK/Iki8t7Uc9x5mn04SIwoSf/vAn2GouoFkzYSoIduIQa 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, Mar 01, 2023 at 05:57:08PM -0500, Peter Xu wrote: > On Thu, Feb 09, 2023 at 12:01:59PM -0300, Marcelo Tosatti wrote: > > /* > > - * Fold the data for an offline cpu into the global array. > > + * Fold the data for a cpu into the global array. > > * There cannot be any access by the offline cpu and therefore > > * synchronization is simplified. > > */ > > @@ -906,8 +906,9 @@ void cpu_vm_stats_fold(int cpu) > > if (pzstats->vm_stat_diff[i]) { > > int v; > > > > - v = pzstats->vm_stat_diff[i]; > > - pzstats->vm_stat_diff[i] = 0; > > + do { > > + v = pzstats->vm_stat_diff[i]; > > + } while (!try_cmpxchg(&pzstats->vm_stat_diff[i], &v, 0)); > > IIUC try_cmpxchg will update "v" already, so I'd assume this'll work the > same: > > while (!try_cmpxchg(&pzstats->vm_stat_diff[i], &v, 0)); > > Then I figured, maybe it's easier to use xchg()? Yes, fixed. > I've no knowledge at all on cpu offline code, so sorry if this will be a > naive question. But from what I understand this should not be touched by > anyone else. Reasons: > > (1) cpu_vm_stats_fold() is only called in page_alloc_cpu_dead(), and the > comment says: > > /* > * Zero the differential counters of the dead processor > * so that the vm statistics are consistent. > * > * This is only okay since the processor is dead and cannot > * race with what we are doing. > */ > cpu_vm_stats_fold(cpu); > > so.. I think that's what it says.. This refers to the use of this_cpu operations being performed by the counter updates. If both the updater and reader use atomic accesses (which is the case after patch 8: "mm/vmstat: switch counter modification to cmpxchg"), and CONFIG_HAVE_CMPXCHG_LOCAL is set, then the comment is stale. Removed it. > (2) If someone can modify the dead cpu's vm_stat_diff, The only context that can modify the cpu's vm_stat_diff are: 1) The CPU itself (increases the counter). 2) cpu_vm_stats_fold (from vmstat_shepherd kernel thread), from x -> 0 only. So you should not be able to increase the counter after this point. I suppose this is what this comment refers to. > what guarantees it > won't be e.g. boosted again right after try_cmpxchg() / xchg() > returns? What to do with the left-overs? If any code runs on the CPU that is being hotunplugged, after cpu_vm_stats_fold (from page_alloc_cpu_dead), then there will be left-overs. But such bugs would exist today as well. Or, if that bug exists, you could replace "for_each_online_cpu" to "for_each_cpu" here: static void vmstat_shepherd(struct work_struct *w) { int cpu; cpus_read_lock(); /* Check processors whose vmstat worker threads have been disabled */ for_each_online_cpu(cpu) {