Date: Fri, 12 May 2017 06:56:55 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219213] powerd causing problems with ryzen Message-ID: <bug-219213-8-sJZLwRCEm3@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219213-8@https.bugs.freebsd.org/bugzilla/> References: <bug-219213-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219213 --- Comment #5 from SF <shitman71@hotmail.com> --- After sleeping and reading the stuff from powerd++ over and over again to understand it there is just one problem to my idea and this is responsivene= ss. I dont know how the load is calculated while the cpu is throttled down to p-state 0, can they still calculated what would be the load if the cpu would run at max. p-state or can they only retrieve the load out of the current clock? -powerd++ sets the clock frequency according to a load target, i.e. it jumps right to the clock rate it will stay in if the load does not change. It will take 4 seconds within my example to push the cpu from p-state 0 to p-state 4, halfing the primary interval to 500ms will get it to 2s but still far too low. Advantage of mine is it will be much more stable and accurate to set the tr= uely needed p-state. Powerd++ will skip high-spikes, always averaging the p-state down to a lower one. It doesn't respond to high-spikes or goes bungee. Both of this doesn't solve this, on server's and for gaming there is circumstances you need the highest p-state to avoid hitting the caps while = such spikes occur. You could add an option to boost the cpu to p-state 4 within under 500ms and take the other calculations to make it slowly throttle down after this. This will increase responsiveness under such circumstances but might also cause = the cpu to get stuck within a high p-state because of some few spikes each seco= nd. Atm i have problems solving this because reacting to high spikes might make= the cpu never leave a high p-state. If there is just one high-spike per second which needs the p-state 4 then it is completely unnecessary to make the cpu boosting into this state. Exceptions to this are servers at specific times = with users often causing such kind of spikes, there might be reasons to deliver a high quality experience to them. Within games there is also reasons to react onto such spikes but if this is the case the gamer will turn off its power-saving-features. This is something different to having a server, the admin cannot always interact with the machine to fit the current required n= eeds of performance. Adding another option to set-up specific times for enabling the boost-funct= ion might be usefull, you could also make the computer watching this over a long period of time like one month to make it decide itself when it is the time = to enable the boost. There is no other way solving this dilemma. Increasing responsiveness will always lead to periods with higher p-states = then might be needed. The powerd++ solution is faster but cannot react onto spikes, its flattening your performance down. There is no priority's to set and no counters to dif= fer between what is needed, it also only reacts always to one single core which= is the core with the highest load. -powerd++ supports taking the average load over more than two samples, this makes it more robust against small load spikes, but sacrifices less responsiveness than just increasing the polling interval would. Because only the oldest and the newest sample are required for calculating the average, = this approach does not even cause additional runtime cost! I think powerd++ is something for old and slow cpu's, on a Ryzen R7 1700X i have 16 Cores i need to take care of and there is no problem giving such mo= re complicated calculations to one spare core. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219213-8-sJZLwRCEm3>