Download raw body.
improvement of perfpolicy auto
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.
improvement of perfpolicy auto