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 89ECBC678D4 for ; Thu, 2 Mar 2023 10:43:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A342E6B0071; Thu, 2 Mar 2023 05:43:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E25D6B0073; Thu, 2 Mar 2023 05:43:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8AA446B0074; Thu, 2 Mar 2023 05:43:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 797246B0071 for ; Thu, 2 Mar 2023 05:43:05 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 43A81120E65 for ; Thu, 2 Mar 2023 10:43:05 +0000 (UTC) X-FDA: 80523620730.09.ED3BE92 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 128EAC0012 for ; Thu, 2 Mar 2023 10:43:01 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=iys+dBi0; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677753782; a=rsa-sha256; cv=none; b=78jtO4mlVOhJf43GZ8N/9LIKaDxAGpwjMHLX+NWIezXgbRcSDLGrJbj3j9wcE9DJNDNFG+ 19Nw2tL1G8iM4gbI20bmkHBEOiDrhZH1LXEp3UXvytlZQvGymNDLcPkSaqtr0gTPiOhW23 btHVVa9TCljpWl9bWi67VuzMQh/ixSw= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=iys+dBi0; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677753782; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LwuiHsJbK4HjQfWeCHu6jHFclxSsPty9CQBgqZ7WAqE=; b=60sZpPLp0TpHA/iO0ltrk/64KCWUpfcWCKUzWyPzi8Io8p5FT5DZBgPOHB7WTJUM6kB0ts 6JyRDKXXW2zem7xd2lhNNqgIAhTGSV7MubKW/moGjhOK5xWIetr+sTicmE7bjwmoNlIS5O /BIr9ly186dHhOikEJMi4QQzz4Hb328= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677753781; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LwuiHsJbK4HjQfWeCHu6jHFclxSsPty9CQBgqZ7WAqE=; b=iys+dBi0wq58SH5JeFeDRKNAuK/Ic2DeNaVMtIwO2HlrBqPwSM7BwPG0V8lWp3XxN0nrHI oUMBp4sVDp3ArON/m9OK2ESZCPSs9Z2tiEMBumAjjoSc1/GycOjDfihkqUJ+ufu1+GksnE YcuOLnu+OUiGhlCW//fGAq7HzeIe+KU= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-107-_Or8uwJ5OGyvwMYWV6eujg-1; Thu, 02 Mar 2023 05:43:00 -0500 X-MC-Unique: _Or8uwJ5OGyvwMYWV6eujg-1 Received: by mail-wm1-f72.google.com with SMTP id x18-20020a1c7c12000000b003e1e7d3cf9fso1086274wmc.3 for ; Thu, 02 Mar 2023 02:42:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LwuiHsJbK4HjQfWeCHu6jHFclxSsPty9CQBgqZ7WAqE=; b=LxucMHftCo3Vs09FNoSo4d3c+gIFX/qTDZ+tCa+KwI//RJFsZ3m4ZPF0FP5pdItU+e GSl7Qofx4Iw/AsL57S0J+ImrI+4Dsm4mtOUYYNLKxiSmYd1PqsDS/KotMHkw5H//vtjU h6Hd9A5zymUUQeU+02esdLtekmzrqyFSwlqrUqwd4B/I2sJEyGVmcYp2ZEcjwEcHxnJs bqzYjBZ/ehW9Tm4w9RyD59JwXMI3h2310diY3rOFVsEkcFJ+iMero+IhRU2Yeh264+ho VJZbO7EBHBvoUZOopriQEWPSg5+JfO2yt/uma9ebg5BHxVom45dF5tt+mZj81SCGSeI3 jj9w== X-Gm-Message-State: AO0yUKXu/oy69HuYrMy+5xlARREuADZW4U3xmlpe/+HmljMw6KhpbAZj 2NE7SESzkgDDVG/iN+OlWvXolEaAwr/hQzkN4Zj0VVIMc6ToA15IlvVJcHEeOWxI6w+IRD91hqA 5AbVbkEc8NZOQdwIg X-Received: by 2002:a05:600c:310e:b0:3eb:3148:a1b7 with SMTP id g14-20020a05600c310e00b003eb3148a1b7mr7520188wmo.12.1677753779066; Thu, 02 Mar 2023 02:42:59 -0800 (PST) X-Google-Smtp-Source: AK7set/fqdVdmgSoTuzweDrtlFiBPO15ZlxWorlkmzaBBGqAUw6q5fq4Fe34ka7WUUel/XXI1jFs8g== X-Received: by 2002:a05:600c:310e:b0:3eb:3148:a1b7 with SMTP id g14-20020a05600c310e00b003eb3148a1b7mr7520176wmo.12.1677753778701; Thu, 02 Mar 2023 02:42:58 -0800 (PST) Received: from ?IPV6:2003:cb:c70e:4f00:87ba:e9e9:3821:677b? (p200300cbc70e4f0087bae9e93821677b.dip0.t-ipconnect.de. [2003:cb:c70e:4f00:87ba:e9e9:3821:677b]) by smtp.gmail.com with ESMTPSA id s19-20020a05600c45d300b003df7b40f99fsm2855839wmo.11.2023.03.02.02.42.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Mar 2023 02:42:58 -0800 (PST) Message-ID: Date: Thu, 2 Mar 2023 11:42:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 To: Marcelo Tosatti , Christoph Lameter Cc: Aaron Tomlin , Frederic Weisbecker , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20230209150150.380060673@redhat.com> <20230209153204.683821550@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2 02/11] this_cpu_cmpxchg: ARM64: switch this_cpu_cmpxchg to locked, add _local function In-Reply-To: <20230209153204.683821550@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 128EAC0012 X-Rspamd-Server: rspam01 X-Stat-Signature: 16b7z6eo6ehmec44tufn31wawiie1isp X-HE-Tag: 1677753781-668743 X-HE-Meta: U2FsdGVkX18l69sSvQ5rwLld7j7ru8wwC+1zL92C6Kevp8qtfAB5iMe6C00FKpXapD2q2Iwz8fRZ9t3St0xFM/NHcNb2Y/2cpM74efEHemeQBMLf3aMI9d9z0WvduJO50bFz12L27y2s+EYr7eTVdQ6UCC2CmhAFcgEos+f1eR6jfJA6v/hwLGHBdz9E+1lbgCaCDv8s9anRqse7eqNrXJFAUmo9bl1lpSzryY1FvMJg85i8yZl5kWAMXuNQBBOIbisZPLlsqtB9lKzONppavh8w4BO1tbwc8RD66K2k53OtgzBiELzDokHC0wkeJ3HKOxkyrDooxdPqYgSgJl7bPljCM+8DP3Tp6487e/temLxwrrYFe73+WjUnCpI7s6xMwRtBtluE+Je+4cgQg1uM4OGH7tASW9bpcOKWCLDI2+2SKWQnMyKyU8B3ULZLyu6ybPqUMW3qC3DocbH3hpWd1eHdP4tOvMCsMmZlwTbghwqWwKFcuvrr/1TJgKlIyIONb5RIDAcAVSjo6Dzo4GbsJVOopaalwAGsEKe75H/V6ZA87k4rn4BJzn3EdizP2nKtg79i2OONWlSsO1rNzeamq5/J7PtQy/rxMZWCfyHHRZ5BSKZfqQPKBDzi1Ug2aI3P91XkKcj5JrM680Uo973pqssbHAHqyhYMvPu5kFe5sAumDVnv8veHbzTUroi/eb4jp03p/n8+Ti9DdH+bm23BMfr0m65W0cYCjcBuUm8zSBDQ7UIWoctfGJFG2WOA2XpFg8tMhLa5SNekDP0T5Nhl/k0E/NSl8TsHrri3Fm975wV06kMF7i8mi49N0asghs0SL3MvBkOi49KHZ8bUWjljq8c6x4riYsNMGG6DxYa9oEvZnQGhdocgBZqVNiESUlsRcuGQjJOrQKA9hFQRtKAGt1lb29hF64BpWWINx58AmQeDE70BkWPtUF1OOwIzih2gjnp+hoEuFId3W3+WoK9 dC7ln+ec 3wBd9MBRk5CiMwXgztpQiw25h3rcq4a7nEihxIrXMqzhX3V07PeN9Gfw/b9/3K2I2k+XELI0zeeGVflGoTm7RH6qFQybkNnFUW6FXceDc4pu/ZESznyxpu5AMUIcEioLIZjDsX9+w5WwPLSgwy+hVivs1/ku55w3wnnPFeWB8wTmwL7wjqJEh9wOw5NNhh/p4NdkVJf1Zgv7VrLcCNFj0fxQF84XIzNQtjXaJvdl7fJNCanj4KkWawO8xzxxJKqPMnJ1pfNISF+nG3zfGZ/CQzcFbUIQJ4OXNx6nctwZiJrTBKkHWZvjVB7ASTLy2xP8wHKSwzCaNSrB/4ykCSJ0wSSovX8EDHk7SNE1FGCwoiMKcNcJbinOxx6o78yPT6QP9FvmrwpsMK9lFoPvh0uwCKjjz4y/fHrnpSoMw3GFDCLtSCoOdLfa8xpTNbNEqM7u5Th8eNGTTd110cv0VmKSKcGO6GA== 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 09.02.23 16:01, Marcelo Tosatti wrote: > Goal is to have vmstat_shepherd to transfer from > per-CPU counters to global counters remotely. For this, > an atomic this_cpu_cmpxchg is necessary. > > Following the kernel convention for cmpxchg/cmpxchg_local, > change ARM's this_cpu_cmpxchg_ helpers to be atomic, > and add this_cpu_cmpxchg_local_ helpers which are not atomic. > > Signed-off-by: Marcelo Tosatti > > Index: linux-vmstat-remote/arch/arm64/include/asm/percpu.h > =================================================================== > --- linux-vmstat-remote.orig/arch/arm64/include/asm/percpu.h > +++ linux-vmstat-remote/arch/arm64/include/asm/percpu.h > @@ -232,13 +232,23 @@ PERCPU_RET_OP(add, add, ldadd) > _pcp_protect_return(xchg_relaxed, pcp, val) > > #define this_cpu_cmpxchg_1(pcp, o, n) \ > - _pcp_protect_return(cmpxchg_relaxed, pcp, o, n) > + _pcp_protect_return(cmpxchg, pcp, o, n) > #define this_cpu_cmpxchg_2(pcp, o, n) \ > - _pcp_protect_return(cmpxchg_relaxed, pcp, o, n) > + _pcp_protect_return(cmpxchg, pcp, o, n) > #define this_cpu_cmpxchg_4(pcp, o, n) \ > - _pcp_protect_return(cmpxchg_relaxed, pcp, o, n) > + _pcp_protect_return(cmpxchg, pcp, o, n) > #define this_cpu_cmpxchg_8(pcp, o, n) \ > + _pcp_protect_return(cmpxchg, pcp, o, n) > + > +#define this_cpu_cmpxchg_local_1(pcp, o, n) \ > _pcp_protect_return(cmpxchg_relaxed, pcp, o, n) > +#define this_cpu_cmpxchg_local_2(pcp, o, n) \ > + _pcp_protect_return(cmpxchg_relaxed, pcp, o, n) > +#define this_cpu_cmpxchg_local_4(pcp, o, n) \ > + _pcp_protect_return(cmpxchg_relaxed, pcp, o, n) > +#define this_cpu_cmpxchg_local_8(pcp, o, n) \ > + _pcp_protect_return(cmpxchg_relaxed, pcp, o, n) > + Call me confused (not necessarily your fault :) ). We have cmpxchg_local, cmpxchg_relaxed and cmpxchg. this_cpu_cmpxchg_local_* now calls ... *drumroll* ... cmpxchg_relaxed. IIUC, cmpxchg_local is only guaranteed to be atomic WRO the current CPU (especially, protection against interrupts when the operation is implemented using multiple instructions). We do have a generic implementation that disables/enables interrupts. IIUC, cmpxchg_relaxed an atomic update without any memory ordering guarantees (in contrast to cmpxchg, cmpxchg_acquire, cmpxchg_acquire). We default to arch_cmpxchg if we don't have arch_cmpxchg_relaxed. arch_cmpxchg defaults to arch_cmpxchg_local, if not supported. Naturally I wonder: (a) Should these new variants be rather called this_cpu_cmpxchg_relaxed_* ? (b) Should these new variants rather call the "_local" variant? Shedding some light on this would be great. -- Thanks, David / dhildenb