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 BA128C6FA8E for ; Thu, 2 Mar 2023 20:06:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2784A6B0071; Thu, 2 Mar 2023 15:06:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 201AE6B0073; Thu, 2 Mar 2023 15:06:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07B7D6B0074; Thu, 2 Mar 2023 15:06:36 -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 E31086B0071 for ; Thu, 2 Mar 2023 15:06:35 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A4E5D1C69A5 for ; Thu, 2 Mar 2023 20:06:35 +0000 (UTC) X-FDA: 80525040750.02.83D9A70 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf27.hostedemail.com (Postfix) with ESMTP id 89DFD40028 for ; Thu, 2 Mar 2023 20:06:33 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="TFLGxl1/"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf27.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677787593; 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=LulnG+Y3EN4uHVj7EFNNPoUgBx7UJRXf/9ipLLQ176Y=; b=ppN/Xx2Vyefc6FUSUSLklm2LIdkyWeAEUQtQbJ/smYpn2y9ANUb5IFP3fJpR1QEpJn92lk WuqKOTF1hUDUrZzMmVoAWaYiRX+Dgi+v+qlLUsbP9tFcgf5kN4+f73IAa/mkI2Ef12SMV5 1DP7U+AuUC6BAN5vHNwsB6p+leDchSE= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="TFLGxl1/"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf27.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677787593; a=rsa-sha256; cv=none; b=VCpSPBpiJrP0R+yTe7Nxh7XuHxbJlOsDCpWdnuCjfz6s5oK3YgBwLnrF02WPV/LYK7/78B X+skU7+/WCSKFnWz2/OGsDInLOxzXMTlRo/cFMNJHplVWGmPry0ShOW6333tmiH9xtfwP1 bMfVgaae+Mjf6di4pYRbJ5mdAazgH3U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677787592; 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=LulnG+Y3EN4uHVj7EFNNPoUgBx7UJRXf/9ipLLQ176Y=; b=TFLGxl1/va07qUOgd0cm4X7s7RVXRP1ybb0JU+IEqmm4SjNm+5Td00hFEWR3pjknNr6tQ7 uNJlEaRwfxEMEMCttOpblyKzkphpZkI8KbYM2bkhwNfqmKbNjMmw9jNv1A/vY/29H2NeYj FAQZhdZ6c/v3sbxF/UQYxhDgsGjsjwk= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-286-HUT8CHCOMoaH5pG_K63_6Q-1; Thu, 02 Mar 2023 15:06:31 -0500 X-MC-Unique: HUT8CHCOMoaH5pG_K63_6Q-1 Received: by mail-qt1-f197.google.com with SMTP id g11-20020ac8774b000000b003bfa92f56cbso259633qtu.3 for ; Thu, 02 Mar 2023 12:06:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677787591; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LulnG+Y3EN4uHVj7EFNNPoUgBx7UJRXf/9ipLLQ176Y=; b=N+ZzTPXRp7hom2BoykcjyzmziGTg/rxvWJPoq1rGNrHvRII1Y0pfvM491YKfhPX3J4 aPG2ESmawLd2Y5umqd7sEwAfmhwr7tqZZU0/2z3VUPiqbAZohMc5aRqCt/RTSJbrZdK3 Fb19Z7dCMe5ESUif9+v30JhUB604yysFQWr6r+NWiq0B7uX7fMr0PZOI0Aj/XrDDNqh7 lFmxW9XNQ0k70EOdYZ/sqFmPw9Pc0c9JdQua5+4pK81UvKd9RXD3p7q4WGIffJWCJX00 MxE9qN/6A8/n/cpJP8o9CzDpMhxhLisL/KGYiY47jPbOSSwI19OtnZXfQyjeLKPh0zYE gHpg== X-Gm-Message-State: AO0yUKXQ0gSmeK6vTqK7dnYhLXLFZHIzDhYGLK+vt8loD+o4gDhoMyfx P3zZAEcWYtaCZzN1HnJGHeP3/qwMjCK9C9YKXafV7kBskPAHPNQ6n6jL0cgnlX/x9b4ZaeZ12ha biOhcnqWkbvs= X-Received: by 2002:ac8:5c86:0:b0:3bf:b0c6:497b with SMTP id r6-20020ac85c86000000b003bfb0c6497bmr21941571qta.2.1677787590789; Thu, 02 Mar 2023 12:06:30 -0800 (PST) X-Google-Smtp-Source: AK7set8mMLe+MEoLiLTnvmOFG32KInqu0sERXBXOI4Jk329xSItvmIZxz1MoHmqJD4M2cPOTgPyOAg== X-Received: by 2002:ac8:5c86:0:b0:3bf:b0c6:497b with SMTP id r6-20020ac85c86000000b003bfb0c6497bmr21941541qta.2.1677787590504; Thu, 02 Mar 2023 12:06:30 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-56-70-30-145-63.dsl.bell.ca. [70.30.145.63]) by smtp.gmail.com with ESMTPSA id h22-20020ac87776000000b003b9a73cd120sm352020qtu.17.2023.03.02.12.06.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Mar 2023 12:06:29 -0800 (PST) Date: Thu, 2 Mar 2023 15:06:28 -0500 From: Peter Xu To: Marcelo Tosatti Cc: David Hildenbrand , Christoph Lameter , Aaron Tomlin , Frederic Weisbecker , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 08/11] mm/vmstat: switch counter modification to cmpxchg Message-ID: References: <20230209150150.380060673@redhat.com> <20230209153204.846239718@redhat.com> <3331790c-95a1-6ab9-2667-86aae3d28d7d@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 89DFD40028 X-Stat-Signature: zkzj34cxeatye3itfioqdo8ju16bamox X-HE-Tag: 1677787593-922458 X-HE-Meta: U2FsdGVkX1+JVFZAh7Vv21d/YU3tjHdus58106QrzFRV1XlAuHYcDNfcSXbHS7bIHVGydFGDdMprOlTz7wPn0wZjbHUD3ne7mBLJxm8xZ77XBB0+IRgevjDZFPplJwczcW1R+rsoAgo6M760fHbz0fL5RjPc7qAYL6HQKW0oXw0yspf/VRdnOjOTMeJy+3PjoFva6xNZQuq/WDxhb3NMf8ZcLmXSvKJoK3Zbj1eoMEfM6f3gkIFpBdu2R8UOeQwsZwFuwqr9Y3H27hvrd8BfQBOmoiHsTh54UNa3+pNPJrIHt9PJlOeTX3SUbxL0jJSTaALz9LEXXTJucNZV9JwbfwFwM7EBvfJ8ssEvgnzt6t2qhMQfmnEi5npgs8Un1k6yiSD+IqEhjuUKtTENYwp2GpJox5uXMNDTxzlddJ6eLXmAaEoMQDtNGEdLCX49niN5HP2F01p6ee+v1v7wKGHub4F/buyqaKq7LZHLJ/JZYEQjDsaSvWWLHlrXoa9ubWYPg1VENrG9eW5FVVFDTdPyEcYP13OsmkF9Q+y0agEIDxrjy6C8conDVfrz9A9ls1l1QWuKXIIzWfVSnfbe70otnGVrAARZVEiLT6CDN8u66Rx7iYIUipEpTapmt2s9r8S7uj24gfT0EvurYOv+548U83FzitaowjzAtRxkzPxn/3Mhx+VY0XfCKQMtpgVM29W/wtgP9g7SkBOEIzX1wa5ZuMndpQCvs46+jHNfBwSO4BUzIp9ZW7mlpsLzNJvgtscV8ja5vHeHCEkPZ16+E3bhkD7e+Wa3JXeRSUk1CuWy7gsc93VCQt4Hpx/ia/nkPyg36A9X9wANa5knGu1foweA2VVvZ5ucYfah7sYa35Q0AWit4Jm/FeRS5VrSGPaA1KECTN/aOmgaHQgwVaLduuA0p8+0yat7p16Bx4OQPfkfk+Sp6VOE1G9FbJ0+aMgP0RzCpbHWGnmcv+eSf75ZsQm Op+kZDrl P/o4L01tr14TZp5xoIEptwAoTVMSBb008NrDspsM9mPV/o9zNur5/X32IWFdVs9i76isYESmRdk1FVkHRsc3mWY3VibE3/ty4ub/0U2RcpobM7zBI25rkaLLNMX/7mFFm+q6qB/uV9x/2G4ooivbq6prf/0npBPNm6lrsqmNXgVPowV6Tr41f5FI4iT4ydyzD8N3/jGd14ybqhWS2DSPfXzrSnpcz+WKnGeztMya5CVJs+IA+zwlRo8+/I3K0MB5ZJ7vfhDTY3X0Og66ecHNaHOIQh6JNrwwy/91mzj5g7AhRx2is6jlkY5i+heTBIpBx8vhjQhd1QRc+eRrHdbW02fOsEREpMkntikvqtsho5v8z9ytQnyZ74jNwK/QTEwA5irTv 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 Thu, Mar 02, 2023 at 04:11:32PM -0300, Marcelo Tosatti wrote: > On Thu, Mar 02, 2023 at 11:20:49AM -0500, Peter Xu wrote: > > On Thu, Mar 02, 2023 at 11:47:35AM -0300, Marcelo Tosatti wrote: > > > So it will be: > > > > > > #ifdef CONFIG_HAVE_CMPXCHG_LOCAL > > > mod_zone_page_state > > > inc_zone_page_state > > > dec_zone_page_state > > > mod_node_page_state > > > inc_node_page_state > > > dec_node_page_state > > > __mod_zone_page_state (new function, calls mod_zone_page_state). > > > __mod_node_page_state (new function, calls mod_node_page_state). > > > __inc_zone_page_state > > > __inc_node_page_state > > > __dec_zone_page_state > > > __dec_node_page_state > > > #else > > > __mod_zone_page_state (old, shared function for both CONFIG_HAVE_CMPXCHG_LOCAL and not) > > > __mod_node_page_state > > > __inc_zone_page_state > > > __inc_node_page_state > > > __dec_zone_page_state > > > __dec_node_page_state > > > mod_zone_page_state > > > inc_zone_page_state > > > dec_zone_page_state > > > mod_node_page_state > > > inc_node_page_state > > > dec_node_page_state > > > #endif > > > > > > Any suggestion on how to split this into multiple patchsets for easier > > > reviewing? (can't think of anything obvious). > > > > I figured this out before saw this, but it did take me some time to read > > carefully into the code base.. maybe it'll be a good idea to mention > > something like above in the commit message to ease future reviewers (and > > more likelyhood to attract the experts to start chim in)? > > > > One fundamental (but maybe another naive.. :) question on this code piece > > (so not directly related to the changeset but maybe it is still..): > > > > AFAICT CONFIG_HAVE_CMPXCHG_LOCAL only means we can do cmpxchg() without > > locking memory bus, > > CONFIG_HAVE_CMPXCHG_LOCAL means cmpxchg_local is implemented (that is > cmpxchg which is atomic with respect to local CPU). > > LOCK cmpxchg is necessary for cmpxchg to be atomic on SMP. > > > however when !CONFIG_HAVE_CMPXCHG_LOCAL here we're not > > using non-local version but using preempt_disable_nested() to make sure the > > read is atomic. Does it really worth it? What happens if we use cmpxchg() > > unconditionally, but just use local (e.g. no "LOCK" prefix) version when > > CONFIG_HAVE_CMPXCHG_LOCAL? > > Can't use local version of cmpxchg because the vmstat counters are supposed > to be accessed from different CPUs simultaneously (this is the objective > of the patchset): > > CPU-0 CPU-1 > > vmstat_shepherd mod_zone_page_state > xchg location LOCK cmpxchg location > > xchg locks memory bus implicitly. > > Is this what you are thinking about or did i misunderstood what you > mean? Yes, I think I wrongly interpreted cmpxchg_local() before on assuming it's still atomic but an accelerated version of cmpxchg() that was only supported on a few archs. I double checked the code and spec on x86 - I believe you're right. Thanks, -- Peter Xu