From nobody Tue Jul 15 21:44:13 2025 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4bhXlC3T1Xz61fgy; Tue, 15 Jul 2025 21:44:23 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bhXlC15ncz3xPj; Tue, 15 Jul 2025 21:44:23 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x82c.google.com with SMTP id d75a77b69052e-4ab5953f5dcso32525891cf.0; Tue, 15 Jul 2025 14:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752615857; x=1753220657; darn=freebsd.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=UudRag4V6mrWb1EFmHqpnecVHehGsXOcxxDXUg3QU5E=; b=cBmhkrRuTnysOwtKnMx368SV/RUaCix0/tA7yGpkJ+yVAQbhdUzW//XxAJi501eYc2 JyCTd1TOt7Jxf/eVQVZqVID7o4n/heDo4h4tqbWcHHDC2ltEje2CZha/xDR/IGgzdn5A H9CisA/nBBpqnYzwq8kPzZLzahKunwUyqEtQ0M9at15ZWLCew2137LVdNiQ8y/HUTPAY 8fsSquafMs6IwXtz5uhXv2XQ3WHXP24oEgb1x09bw5bUadWHWa53h78qAScKXTcHb/OH knHXHUWNSPx1yOxOG3jnECvclubRCBt0aE5e3M8UUZDUmdHIiMYRicBXwbEw9RBnNlDO +qaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752615857; x=1753220657; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UudRag4V6mrWb1EFmHqpnecVHehGsXOcxxDXUg3QU5E=; b=pJ7hBkzRom0gl8HKWxXIZFrDUhy3riKwIAXSeKgY64kfulESAZO52AOhwq+PnykjbN mjWIvhgIqnZExuTVhvD2asTnHs0guYEB4WGh49ZpSLRKUlLqSnbIh3bsXY0uBs+PEV3B KJK4m238ugDXXBuYadio5Qc/DfHCBs3oiWSHjLUQ8W6za/P7IalcB9mK1PsJONeEZicI QcSPV9euGbpnd3w/WVkU/Bp080slb+uYKtI5f4kUaaa/+sT8j54v4Ps2+Ka/oZibfSxo jXGeGYFRg50h5k44vBE8zjf1OgPZQAtjaBeLenlpaUFdyXQKYuuArGsbZ7PyF+387r1/ PrdA== X-Forwarded-Encrypted: i=1; AJvYcCUV2j2i4Gggm7yD//Ae9vbQ0sINgT82VsCjjNNFmGKIf7IySxrEVhtJ6srbs83LVRq4qz6sX/KbOUMeE92HtTYiaMKRlw==@freebsd.org, AJvYcCUZFlZP4lLpdbqlwWns2l1T1CkQ3Je0nwbgS7Tukee0kNXdd0bzPxM1oqMB3Fx3zRBrgxn69XBWTi+H3d1ifpY=@freebsd.org, AJvYcCXgMWlIYvgUGF/gkFlEdt2dAMyluQVr6l1eTuQLqAutVhRPpUym8R9UQ5jxH1vFfeqD4QAFJDm6vJqtwCaSDeOAlJqE5f4=@freebsd.org, AJvYcCXvkpO3DW8jKAMZiOksBw2Vhjqlg6aCqyJHHa0Zm6jYtEjPEzyDRmVLBh0007X/n5VxFgI=@freebsd.org X-Gm-Message-State: AOJu0Yx/VWVuxyWwUJxRObDyI1ueAU9YV329kzFYFiCzKXrOkUnk4fym Vw1wjNGFUacIVLzKHpkPmLnWC0DOlDOMzZrWReb6ej4IO6SvOMvadpd444m6D46Y0aU= X-Gm-Gg: ASbGncuFKjjMo7MgvP8DfY1khdc5gnOiTbcBX7dXB6YyektqcSXiFgbgNFswqwT4NSP GoIklkSnD3qSRwZhteUQSe/G44makBEFaY4dcaPfoixQbfuzn1aHERgwJ5FBX0aq71o97jU0m0X GI5/tzTlAaPlhg3aK+o5xAqW5CERyTXHgUyc8AMP4py0/gyiX6zXtNnMhlfbPtrHIyl13pVRmgx VHXOUj+m3O6YnmUh3YlPRuC8cBJm+nh7iqsJRzQNjgVVCuQWozg1X/V3TcYTRfjwwxJTbKD/yLn i3S9ZXRTLQeVHzfAqgJxomDLbyeb6I1SS/Qp6ntCSRi6icW+IlIoGteAqwH1ubFtsCvx+MxJbN6 c6P6XSY2LjpnjfHkT45RgkL5OO/q6+I6LEuC65zHHi4e09Ow= X-Google-Smtp-Source: AGHT+IFYGpWOY+Rsb/FT6c+SaXHXyGD5lfgod4Syv6Q3Lo0sVtVPWymBw7bKPVlZz1S93IG6l2kXDA== X-Received: by 2002:ac8:5948:0:b0:4ab:4102:50de with SMTP id d75a77b69052e-4ab93d48758mr6769031cf.28.1752615856615; Tue, 15 Jul 2025 14:44:16 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4ab3d44b3d6sm45089821cf.56.2025.07.15.14.44.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Jul 2025 14:44:16 -0700 (PDT) Date: Tue, 15 Jul 2025 17:44:13 -0400 From: Mark Johnston To: Konstantin Belousov Cc: Gleb Smirnoff , alc@freebsd.org, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: fad79db40505 - main - vm_pageout: Remove a volatile qualifier from some vm_domain members Message-ID: References: <202507151519.56FFJ4FS013944@gitrepo.freebsd.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4bhXlC15ncz3xPj X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On Tue, Jul 15, 2025 at 11:04:57PM +0300, Konstantin Belousov wrote: > On Tue, Jul 15, 2025 at 01:24:36PM -0400, Mark Johnston wrote: > > On Tue, Jul 15, 2025 at 09:40:18AM -0700, Gleb Smirnoff wrote: > > > On Tue, Jul 15, 2025 at 03:19:04PM +0000, Mark Johnston wrote: > > > M> The branch main has been updated by markj: > > > M> > > > M> URL: https://cgit.FreeBSD.org/src/commit/?id=fad79db405052f3faad7184ea2c8bfe9f92a700d > > > M> > > > M> commit fad79db405052f3faad7184ea2c8bfe9f92a700d > > > M> Author: Mark Johnston > > > M> AuthorDate: 2025-07-15 15:16:40 +0000 > > > M> Commit: Mark Johnston > > > M> CommitDate: 2025-07-15 15:16:40 +0000 > > > M> > > > M> vm_pageout: Remove a volatile qualifier from some vm_domain members > > > M> > > > M> These are always accessed using atomic(9) intrinsics, so do not need the > > > M> qualifier. No functional change intended. > > > M> > > > M> Reviewed by: alc, kib > > > M> MFC after: 2 weeks > > > M> Sponsored by: Modirum MDPay > > > M> Sponsored by: Klara, Inc. > > > M> Differential Revision: https://reviews.freebsd.org/D51322 > > > > > > What's the benefit of removing the qualifiers? They act as documentation > > > and they match atomic(9) prototypes. To me this looks like removing a > > > const qualifier with a reasoning that we use the variable only as an > > > argument to functions that have const qualifier. > > > > Note that I updated the comments as well to indicate that accesses to > > the fields should be done through atomic(9), so the documentation is > > preserved. > > > > The reason atomic(9) prototypes include the volatile qualifier is to > > permit their use with volatile-qualified variables without a cast, not > > because the interface expects only volatile-qualified parameters. > > > > More generally, I believe that new code should always avoid using > > volatile to provide any kind of synchronization, ignoring the case of > > accesses to memory mapped with non-default attributes. atomic(9) > > intrinsics should be used where they are needed, and some comments > > should explain the synchronization protocol if it's not obvious. > > Hmm, when I wrote atomic_load/store(), volatile casts were used to utilize > compiler-specific semantic of volatile accesses, that happens to match > what loads and stores should do (access that place now). I.e. it is not > for the allowance to use volatile-qualified locations, but to provide > the C11-compatible semantic. My understanding is that C11 atomic ops take volatile-qualified parameters for the reason I gave above. There is a note in the standard which suggests this: NOTE Many operations are volatile-qualifed. The ‘‘volatile as device register’’ semantics have not changed in the standard. This qualifcation means that volatility is preserved when applying these operations to volatile objects. I see similar hints here, but I don't know what source this is based on: https://en.cppreference.com/w/c/atomic/atomic_load.html > After stating that, it is clear why qualifying the vars with volatile > is not what we want: the semantic of volatile is compiler-dependent, > and it only happens to match what is really used for code. Atomics > loads and stores do provide the primitive ops we need, and hide the > compiler-specific implementation under. > > I.e., volatile should *not* be used.