Created attachment 255443 [details] dmesg Hello, I'm on the kernel 4.10.4 but I've had the same issues for a few weeks already, definitely on .3 and probably on .2 but not sure anymore. When I switched the cpu governor from ondemand or performance to schedutil, it all seemed fine, but actually playing a game in wine gives me audio cracking every now and then, fairly similarly to when we didn't have a pulseaudio backend in wine. (I have not tried using only alsa). Interestingly I've tried 2 different games in Wine and the problem only happens with one, I assume the more CPU intensive one: StarCraft 2. Restarting the computer, killing pulseaudio and restarting it, limiting the apps opened, not of that changed anything, but switching the governor back fixed it right away. My CPU is an Intel i7 4790k, this is my kernel line: linux /vmlinuz-linux root=/dev/sda3 rw rootfstype=btrfs raid=noautodetect intel_iommu=on quiet add_efi_memmap clocksource=hpet hpet=enable splash consoleblank=0 intel_pstate=disable sysrq_always_enabled=1 I am not sure what else to provide, there was nothing in dmesg that seemed related, nor any error in Wine, please tell me how I can help. Thank you, John
I just tried a few more tests: 1) pstate's powersave: no issue (but it also doesn't scale for me...) 2) cpufreq's powersave: I have more the issue than not (in my original posting it was maybe once every 2 seconds or so, in this case it's much more frequent). 3) cpufreq's conservative: better than powersave but still no good. 4) cpufreq's ondemand: all good as expected. Based on that I'm guessing it's scaling related.
John, Can you please give us the value of /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us ? Try making this around 10000 (10ms). This is how frequently we try to change the frequency and lowering it will make us more aggressive.
It also would be good to test this patch: https://patchwork.kernel.org/patch/9637821/ and maybe also this one: https://patchwork.kernel.org/patch/9640261/ to see if it improves things for the intel_pstate "powersave" on that machine.
(In reply to Viresh Kumar from comment #2) > John, > > Can you please give us the value of > /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us > > ? > > Try making this around 10000 (10ms). This is how frequently we try to change > the frequency and lowering it will make us more aggressive. Hello Viresh, cat /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us 10000 It's already at that value, are there others you'd like me to try? (In reply to Rafael J. Wysocki from comment #3) > It also would be good to test this patch: > > https://patchwork.kernel.org/patch/9637821/ > > and maybe also this one: > > https://patchwork.kernel.org/patch/9640261/ > > to see if it improves things for the intel_pstate "powersave" on that > machine. Hello Rafael, I will try these and report. Does it matter if I use both patches together? Thank you!
No, you can apply them both at the same time.
The schedutil patch didn't seem to change anything, though the 4th hunk of cpufreq_schedutil.c didn't apply and I had to do it manually, so it is possible I messed up somewhere (I copied/pasted it so it's unlikely, but I thought it'd be better to say it). As for pstate, I think that's the first time I've seen my CPU scaling on pstate's powersave. I've tried the game, and I think, but not sure, that when it started the sound cracked for just a bit, maybe before the CPU scaled up enough? After that no issue, and I verified the CPU was at its maximum frequency. When I quit the game, the CPU scaled down to its minimum frequency within 2 seconds. Pstate's performance still doesn't scale, is it expected? I thought on pstate both would. Thank you!
(In reply to John from comment #6) > The schedutil patch didn't seem to change anything, though the 4th hunk of > cpufreq_schedutil.c didn't apply and I had to do it manually, so it is > possible I messed up somewhere (I copied/pasted it so it's unlikely, but I > thought it'd be better to say it). OK, this means that schedutil is not a good match for you. It is a bit less aggressive than ondemand, on purpose. There is one more schedutil change that you may try, but I need to prepare a patch for that first. > As for pstate, I think that's the first time I've seen my CPU scaling on > pstate's powersave. I've tried the game, and I think, but not sure, that > when it started the sound cracked for just a bit, maybe before the CPU > scaled up enough? Yes, that's possible. > After that no issue, and I verified the CPU was at its > maximum frequency. When I quit the game, the CPU scaled down to its minimum > frequency within 2 seconds. Pstate's performance still doesn't scale, is it > expected? I thought on pstate both would. If you mean scaling_governor=performance, then it will always request the max P-state now, as that's what it is supposed to be doing. Thanks for the testing, the intel_pstate change will be queued up for 4.12 in the next couple of days.
(In reply to Rafael J. Wysocki from comment #7) > OK, this means that schedutil is not a good match for you. > > It is a bit less aggressive than ondemand, on purpose. Oh I see, I didn't realize that, I thought it was about as dynamic as ondemand. Then I am sorry about a wrong report! > There is one more schedutil change that you may try, but I need to prepare a > patch for that first. > I'll be happy to test it whenever it's ready. Since I have plenty of workaround there's of course no sense of urgence on my end. > If you mean scaling_governor=performance, then it will always request the > max P-state now, as that's what it is supposed to be doing. Yes that is what I meant, I thought scaling_governor=performance with driver=intel_pstate would scale unlike with driver=cpufreq, I was wrong again. > Thanks for the testing, the intel_pstate change will be queued up for 4.12 > in the next couple of days. Well thank you for this patch, I am happy to finally be able to use pstate :) If you don't mind me asking here, since we talked about many different governors, and their drivers, which one do you recommend for a desktop, that does run games, but also other things that don't require much power. Based on my tests I'm thinking either cpufreq's ondemand or pstate's powersave. Thank you!
I would use intel_pstate "powersave" (with the patch you have tested applied). One more question, though. I guess that you used "schedutil" with acpi-cpufreq as a scaling_driver? If that's correct, can you please also try to run intel_pstate in the passive mode (that is, pass "intel_pstate=passive" to the kernel command line) and use "schedutil" with that (scaling_driver will show "intel_cpufreq" in that configuration)? With acpi-cpufreq "schedutil" may under-provision things due to the way in which turbo P-states are represented in the ACPI tables.
(In reply to Rafael J. Wysocki from comment #9) > I would use intel_pstate "powersave" (with the patch you have tested > applied). > Alright. > One more question, though. > > I guess that you used "schedutil" with acpi-cpufreq as a scaling_driver? > Correct. > If that's correct, can you please also try to run intel_pstate in the > passive mode (that is, pass "intel_pstate=passive" to the kernel command > line) and use "schedutil" with that (scaling_driver will show > "intel_cpufreq" in that configuration)? > > With acpi-cpufreq "schedutil" may under-provision things due to the way in > which turbo P-states are represented in the ACPI tables. I just tested it, and still had the audio cracking. I'm not convinced it was any different from using it with acpi-cpufreq, but since I don't measure the time between audio distortions I could be wrong. Thank you!
Created attachment 255621 [details] cpufreq: schedutil: Ramp down frequencies slower One more patch for the schedutil governor to test. It should make it ramp up frequency faster, so maybe it will help. :-)
I forgot to say that the patch in comment #11 is based on the current linux-next branch of the linux-pm.git repository: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-next and it should be safe to test it along with that branch.
I've tested it quickly and it seems to work just fine. I've re-used my 4.10 kconfig file, and defaulted every new other option. I'll keep running it and we'll see. Is it ok that I didn't test the repository without the extra patch? Thank you!
Well actually it's not good enough for me yet, I still get the audio issue, very rarely though. I'll switch to ondemand on the same kernel and see if I also get it (since it's a different kernel who knows...).
Just to be sure that nothing escapes us, can you please test the patch on top of the linux-next branch *and* with intel_pstate in the passive mode (intel_pstate=passive) instead of acpi-cpufreq?
Well I've had the same issue on ondemand, then I switched to performance to see and it was all fine, I switched back again to schedutil and since then it's been fine. So maybe it was a heavy service running in the background at that time or something like that... Based on that, I will retract comment 14. I will test it with intel_pstate=passive and report.
Cool, thanks!
So I've been on passive for about a day, and I didn't notice any difference with acpi-cpufreq. As you've correctly stated in your email, I am not doing any measurements so it's all a bit of a guesswork. I could plot frequencies if needed. One thing I forgot to mention earlier is that I use the most cpu intensive resample method in pulseaudio (speex-float-10). On another forum, one user tried to replicate my tests and never had any issue or worse performance with standard schedutil from 4.10 on a 2500k. I don't know if he's using pulse or straight alsa, and if the former which resampler is used. I'll try to get this information. Not sure what that means, but I thought I might as well share this.
What it practically means is that the problem reported by you may be hard to reproduce. :-) Anyway, my conclusion is that the patch from comment #11 (or alternatively https://patchwork.kernel.org/patch/9655173/) helps, so let me resolve this report accordingly. Whether or not the patch is accepted upstream, I'm not sure at this point, because it may lead to increased energy consumption on other systems in principle.
Sure that's fine. Assuming the patch will be accepted, what governor would you now suggest me to use on what will be 4.12? Thank you very much for your super quick help on this!
(In reply to John from comment #20) > Sure that's fine. > > Assuming the patch will be accepted, what governor would you now suggest me > to use on what will be 4.12? If it is accepted, there won't be much difference between schedutil and the new "powersave" algorithm in intel_pstate, so whichever of the two you prefer I suppose. :-) > Thank you very much for your super quick help on this! No problem.
I've just seen the patch has been checked in, so thank you :)