On Fri, Aug 19, 2022 at 08:41:57AM +0300, Mikhail wrote: > Recently I've bought subject laptop, but it had an issue - when I was > doing git clone of a any huge tree, like linux kernel, it shut down in > the beginning of 'Resolving deltas' stage. I'd tested Debian 11 and > OpenBSD (current) - Debian shut down almost immediately, OpenBSD was > working randomly but about ~3 minutes. > > Service guys set up Windows 10 on it and git clone worked fine there, > they also did AIDA64 stress testing for a day, and I'd tested latest > Ubuntu 22.04.1 and it worked without the issue. I did some digging and > came up with this commit: > > --- > commit 086aa750ab8f1698a6c6eaafe1458279776ce66d > from: tb <t...@openbsd.org> > date: Wed Aug 11 18:15:50 2021 UTC > > Make hw.setperf percentages proportional to the enhanced speed step > frequencies on intel processors. This way, the default hw.setperf=99 > corresponds to the maximum ordinary speed while setting it to 100 > enables turbo mode. > > Tested in snaps for a week, positive feedback from several. > > M sys/arch/amd64/amd64/est.c > --- > > Apparently setperf was set to 100, and if the CPU works in that "turbo > mode" for long enough it overheats and shuts down (sensors shows > temperature of ~100C while in 'Resolving deltas'). > > Work around was to set: > hw.perfpolicy=manual > hw.setperf=99 > > I was watching how Windows 10 behaves and noticed that when CPU > intensive thing starts - it boosts CPU for 100% for about 5 seconds and > then drops it to 85% and continue to work in this mode till the end of > the task. > > My previous laptop is around 12 years old, so I don't follow how modern > HW in this segment works, I was told that current laptops can work in > high speed mode only for a while, and then they should back to normal > speeds, otherwise behavior is unpredictable (as with this one). > > I'd like to know from your experience - is that shitty cooling design > from Lenovo, or the OSes should be more careful about setting turbo > mode? Since the commit is 1 year old and no one complained, I assume > it's first, but would like to know opinion of the list.
It is known bad behavior of OpenBSD for which no-one has proposed an acceptable solution. My commit didn't really change the scheduler's behavior. Rather it addressed how the percentages are mapped to different frequencies. Previously, setting the setperf to 75 would enable turbo mode on some machines. You're much more likely to be bitten by this change: https://github.com/openbsd/src/commit/0294e0be5821991219b454f4fdc27f570d30a6fd which enables turbo mode by default as soon as a machine is plugged to hw power. There's been a lot of dicsussion and quite a few patches to address this situation. No proposed solution was deeemed adequate. The old code wasn't great either. Unless you want to patch the kernel (e.g. do "if (0 && hw_power)" in the appropriate place), you're forced to use your workaround. Some people also recommend the obsdfreqd port.
