On Thu, 22 May 2025 00:17:43 +0200,
Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> 
> > From: "Ted Unangst" <tedu@tedunangst.com>
> > Date: Wed, 21 May 2025 13:58:13 -0400
> > 
> > On 2025-05-21, Kirill A. Korinsky wrote:
> > > tech@,
> > > 
> > > Here a diff which makes hw.setperf MP safe.
> > 
> > Am I out of the loop? What machine doesn't load an int atomically?
> 
> https://lwn.net/Articles/793253/
> 
> I'm still not convinced load tearing and store tearing are genuine
> problems.  All the examples I've seen from the Linux developers are
> somewhat convoluted, involving things like unions or type punning.
> But there is currently no consensus among OpenBSD developers.
> 
> But yes, 
> 
> > 
> > > -		perflevel = 100;
> > > -		cpu_setperf(perflevel);
> > 
> > > +		atomic_store_int(&perflevel, 100);
> > > +		cpu_setperf(atomic_load_int(&perflevel));
> > 
> > Constructs like this in particular look weird. If there's a race, 
> > this doesn't fix it.
> 
> It is code like this that makes me believe the current path mvs@ is on
> isn't right.

To be clear: this diff is one of many similar diffs which unlock sysctl.

I need this to construct an experemntal MP-safe setperf policy which can be
run without kernel lock with smaller than 100ms intervals to see how it
goes.

I thought that share it is good idea.

Looks I was wrong.

-- 
wbr, Kirill