Index | Thread | Search

From:
Vitaliy Makkoveev <mvs@openbsd.org>
Subject:
Re: improvement of perfpolicy auto
To:
tedu@tedunangst.com, tech@openbsd.org
Date:
Mon, 19 May 2025 23:57:17 +0300

Download raw body.

Thread
On Sat, May 17, 2025 at 01:07:58PM +0200, Kirill A. Korinsky wrote:
> On Fri, 16 May 2025 02:51:54 +0200,
> Kirill A. Korinsky <kirill@korins.ky> wrote:
> > 
> > On Thu, 15 May 2025 23:25:53 +0200,
> > Vitaliy Makkoveev <mvs@openbsd.org> wrote:
> > > 
> > >                                                          I could say my
> > > gnome session works acceptable.
> > > 
> > 
> > I think that it can be improved. May I ask you to try this version and try
> > different hw.autoperfpolint?
> > 
> > My bet that 100 ms is too slow to change speed and smaller value, like 50 or
> > 10 ms, is that should be used.
> >
> 
> With 35ms I can't reproduce clicking and popping when play 192000Hz flac, see:
> https://marc.info/?l=openbsd-misc&m=174207573216199&w=2
> 

It scales frequency faster, but the cooler behavior is much worse. The
permanent on-off, with very short "on" time, less than one second. With
the 100 ms period cooler works fine. The workload is not extreme, just
gnome session with the only evolution fetching mails.

Please note, the setperf_auto() timeout(9) handler executed with kernel
lock held, so if your workload triggers it, setperf_auto() gets stuck in
lock acquisition. This time all the timeout(9) handlers cross the kernel
lock boundaries via clockintr().

So, I like to have the "smooth" frequency scaling. The current min-max
behavior is something like to Pentium 3 mobile from the early 2000s, but
with the unusable "min" case.