Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp9081936rwl; Wed, 11 Jan 2023 00:56:54 -0800 (PST) X-Google-Smtp-Source: AMrXdXuRDIrloej2b2Apa0v9wSln6RlHTebugDUtBpW0N+aZOycG8EP5hPXPyGo9sgewr5iGdXy+ X-Received: by 2002:a17:906:280d:b0:7c1:65f5:7b95 with SMTP id r13-20020a170906280d00b007c165f57b95mr65142316ejc.26.1673427414163; Wed, 11 Jan 2023 00:56:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673427414; cv=none; d=google.com; s=arc-20160816; b=kQ4G9+03zgYn3T4c8QuAtQ5QKz+ca2pPVknIasIVBJYM6ebprLo5hB2wMxc3EZQpBi 5Ki6KD7rqd2BBxum6PpMENvqxAOmIYQIulaVbNTm9yn++uOY4mkWWs2ZbHRv25I39fK5 bQf1JI99/10+g42Gr3kbrrNYoQAPjrNDrdWvivOjvsNalBv49SOI99hmFHCVqwEsgTpt G2XOEehV5VLe6CnFy+74xkBr0eueFCvwuivGu4L93dbm+n+v+Maccx96oexar5n8Kekp WFkWiVXGwfF7aJ6dgOcZuaiM+ZW+Ty3Ny7781DMJCjQO6L7YnbqP907PVank7gckOaoV w0CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=2eFVv9DIMOW4oli6Yvs6/XW8+Xli3QxJdu7tbCdXOAs=; b=uywn9B9bzbRl+Nk+FESHu4t6U8Dc7F8nhmyuIEtZIJd2kUq3aPI5/8WbuE78UFnwHg ZDZOI5wEhIjtrJzkOXjtoOO3oBeMI8+/PMhQIIzFubzekECNNhxg1hnwq86SzqjAH7NN pIaN8zzqwnLcSDcF9NjlzJUfoviDdqFnf/AttCYPmx67FvJHWG+DInFMhA30/98gSm15 kHl7ZrNX3/2sEs79eWyPBSULri6+M6eu09IuQIRSPjRAPbDa5tnU9gtBwvSVs9umdbdw nf7LgxXBZGOaHFkGG6gPhRs+hWQPklVzSkXCbPjhyP5x8abH0CTirrgVq7gaT4gmsWZy v5KQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gentwo.de header.s=default header.b=wFba+scB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gentwo.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dm8-20020a170907948800b007c08000a65esi16051122ejc.756.2023.01.11.00.56.41; Wed, 11 Jan 2023 00:56:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gentwo.de header.s=default header.b=wFba+scB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gentwo.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230074AbjAKIoU (ORCPT + 53 others); Wed, 11 Jan 2023 03:44:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237809AbjAKIn1 (ORCPT ); Wed, 11 Jan 2023 03:43:27 -0500 Received: from gentwo.de (gentwo.de [161.97.139.209]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66D916542 for ; Wed, 11 Jan 2023 00:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.de; s=default; t=1673426538; bh=KoVgyzHofNvsfxU3iLQZtrwKbN6bHAYrV7gkyQq2px8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=wFba+scBlp5eEKXHkkgePqb6kAocgsKjyyZ1xuBacniGPTplix/P4diFoLgimrbrA q9PbSJUZ/t2AC4/KF/RP4XdAwvxTMP7e10Dk9iizCASAKLO33jvu2syES7yWHs0HxF XMOcWZa/bu0PPCBiqcU42tC80oOwPsLXk4SEpRJe6TJwA7M0A0T/nSawQFkOqEAKA3 cgaHh7cNESHsg2LCvmJQFnb6hARlrmwPjp2Mq8CVYC21tNIqRifkxCYAtSgbcagy5V LLETxp2jq+Fx3RrbJjPjTmAunktIWuLqXZ5EpXKp3JQEDovw9PDzv7XFWruDiEOzk5 h6BDmMKYwmIKQ== Received: by gentwo.de (Postfix, from userid 1001) id B984AB001DF; Wed, 11 Jan 2023 09:42:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by gentwo.de (Postfix) with ESMTP id B7AE2B00129; Wed, 11 Jan 2023 09:42:18 +0100 (CET) Date: Wed, 11 Jan 2023 09:42: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: <60183179-3a28-6bf9-a6ab-8a8976f283d@gentwo.de> References: <20230105125218.031928326@redhat.com> <20230105125248.813825852@redhat.com> <7c2af941-42a9-a59b-6a20-b331a4934a3@gentwo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 10 Jan 2023, Marcelo Tosatti wrote: > > The basic primitives add a lot of weight. > > Can't see any alternative given the necessity to avoid interruption > by the work to sync per-CPU vmstats to global vmstats. this_cpu operations are designed to operate on a *single* value (a counter) and can be run on an arbitrary cpu, There is no preemption or interrupt disable required since the counters of all cpus will be added up at the end. You want *two* values (the counter and the dirty flag) to be modified together and want to use the counters/flag to identify the cpu where these events occurred. this_cpu_xxx operations are not suitable for that purpose. You would need a way to ensure that both operations occur on the same cpu. > > > And the pre cpu atomic updates operations require the modification > > of multiple values. The operation > > cannot be "atomic" in that sense anymore and we need some other form of > > synchronization that can > > span multiple instructions. > > So use this_cpu_cmpxchg() to avoid the overhead. Since we can no longer > count on preremption being disabled we still have some minor issues. > The fetching of the counter thresholds is racy. > A threshold from another cpu may be applied if we happen to be > rescheduled on another cpu. However, the following vmstat operation > will then bring the counter again under the threshold limit. > > Those small issues are gone, OTOH. Well you could use this_cpu_cmpxchg128 to update a 64 bit counter and a flag at the same time. Otherwise you will have to switch off preemption or interrupts when incrementing the counters and updating the dirty flag. Thus you do not really need the this_cpu operations anymore. It would best to use a preempt_disable section and uuse C operators -- ++ for the counter and do regular assignment for the flag.