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 B342EC46467 for ; Wed, 11 Jan 2023 08:42:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 376C18E0002; Wed, 11 Jan 2023 03:42:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 326CF8E0001; Wed, 11 Jan 2023 03:42:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EF9C8E0002; Wed, 11 Jan 2023 03:42:23 -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 11A498E0001 for ; Wed, 11 Jan 2023 03:42:23 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C1CC2C03DB for ; Wed, 11 Jan 2023 08:42:22 +0000 (UTC) X-FDA: 80341876524.14.0E35D7C Received: from gentwo.de (gentwo.de [161.97.139.209]) by imf14.hostedemail.com (Postfix) with ESMTP id ADD7310000F for ; Wed, 11 Jan 2023 08:42:20 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gentwo.de header.s=default header.b=wFba+scB; spf=pass (imf14.hostedemail.com: domain of cl@gentwo.de designates 161.97.139.209 as permitted sender) smtp.mailfrom=cl@gentwo.de; dmarc=pass (policy=none) header.from=gentwo.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673426541; a=rsa-sha256; cv=none; b=jBKZ2QjJYycBqhzWfoNvUjNQpCzGXqFugD/hvy6pMquPLwpgBfWUxyuKo0U1dIQvGiV/YH sbFCI40EchuRV+j4I7Nsaq1dLedqFo3syFSS1XEXQKpRkP6WmWSglKflLQ1dq87aVywoxI loqtliMrN6rDZ8uhdKsspVA/VbGuo/8= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gentwo.de header.s=default header.b=wFba+scB; spf=pass (imf14.hostedemail.com: domain of cl@gentwo.de designates 161.97.139.209 as permitted sender) smtp.mailfrom=cl@gentwo.de; dmarc=pass (policy=none) header.from=gentwo.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673426541; 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=2eFVv9DIMOW4oli6Yvs6/XW8+Xli3QxJdu7tbCdXOAs=; b=bigkfmpTyM4iY5N2qipR/I2GVv2w4X02p1LtVvKZ8WZgNdp4KOebJJ0NfT/G93Qv/S96Fa j1K4J71dSh6AkX0mBIlDClaSG70dYJstoVltiySvVZF5eFRHNapIyjqwAVHWKfMqFwIUvK Hv78o+HJIi8ekERPCCyjVUXj9OE1Fvk= 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-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: ADD7310000F X-Stat-Signature: onxe348rmyddd41barcne1ozyikcyu3x X-HE-Tag: 1673426540-110936 X-HE-Meta: U2FsdGVkX19IxA8OUSAJ+Dapt420v5KvuM4uUzAfJ1Vc/8S+Wfxjg52OcrMqNt33fbfeNLqtVJakKV2fnrB4vASqyZ1Qt21G2cTdwMjrSoNGaYH27MDO6llYpbxe7XGrRZZnqIXN5ql8n1ZzMMqvacffj4qv65+oH6wMgnaJBAauDZSDO2mr/1aI8k6GagrNBIQlt8sFjd6JngZTY5yTIw8iljI83uh7lzpBmVZHmotTiHhJQujbcNqAlh07z+i9jH4YeJAwF/svGRuVE09T7e3NVZr7Vw84/+OdK9LQhbCwRwI/C1YGw+xnLqDsZ9+JDsGKjIXm4ARHEKa+asZHRVsrIWaCUnW/+i1hLEtE/Uf2vJ8kx6y3esNOsDH9WH6ZquZf6+adBF6rsr2mNcocjqG242Mqe42N38DMowHlEczGWydEht8dJee+61r8o0xup/N1tbBzGg1aHxe78YZ+6RWFgiJj0M7EHWQZ4NVi26MiSpq8fKa5XbdrCOUHlgrZ4KFMAqPFYZO+903Su5Go9tvHIqMjIBKFhLvNzBWcORTaVtZULQDN4FMN4G/0+Ceoi2l+ddkLnCsD+geBuDEhEyFJiBVQrfCjpngIwnkhZ1sj0qW1Hv7ffmmmF3l1wnHO8SfVNodoqX6dg4QGStZTIakPZaXMg3wDCOhgFi4r7wfpiraUWraXpyBBRnYWwqypDt2GjI4oUuMYvErwAs3oLKQar4WH11zGk/ImmwxmlWWJe3CcyZNdkT53Aqo+xS4EpoyrlkOOKCTtE8SX4SJW8lZ02enXDzvbuLrJ2iV1AW0jcman8keeqk7XrJPKCyyEHMVaBLgMPu6bcsERQR1mjFAV9cM3Oz/60rdRIHdRpqQF761pyonVyurSDgkfvKjftS0v+wus7sbBVBwx7qMWSA== 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 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.