NNate

Agreed, the above steps solved the problem for a short time, but the issue returned.

I'm having the same "problem". Everything appears to be working as expected, however.

Looks exactly like the problem I had. I followed this guide to deal with my dockers running with specified IPs and I haven't had a crash since putting them in their own vlan.

https://www.spinics.net/lists/kernel/msg3457429.html This seems to suggest to keep pstats_status as passive, but use the schedutil governer. This is what I'm going to go with for the time being.

I'm torn, hard to know what's the best approach: https://wiki.archlinux.org/index.php/CPU_frequency_scaling#Scaling_governors

Yes, that would solve it as well. From what I've read, I don't think "On Demand" is as efficient with the pstates for Intel as the "Power Save".

@jowe I haven't looked to see if your CPU is impacted, but this really helped me:

See the post above yours. It gets loaded directly into ram. Speaking as someone who doesn't have a nvidia card, I personally don't want my ram used up for something I don't have.

Oh yeah, wow "echo active > /sys/devices/system/cpu/intel_pstate/status" really gave my system a kick in the pants. HUGE difference This will hurt a lot of people's performance pre-Skylake. Being stuck at the lowest pstate supported is painful. How can I make sure this change sticks post-reboot? Anything that can be done for others beyond manually making those changes?

This looks very suspect: https://bugzilla.kernel.org/show_bug.cgi?id=209085 when I `cat /proc/cpuinfo | grep "MHz"` it basically only shows 800MHz. cat /sys/devices/system/cpu/intel_p_state/status = passive cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor = powersave Seems like these findings line up with the above linked bug reports/reddit page. Sounds like a very significant issue if you're running Intel pre-Skylake (ie 6th gen processors).

Initial findings are that disabling those mitigations won't make much difference.

I do have the "Disable Security Mitigations" plugin installed. I don't mind turning off the mitigations and running again. Currently rebooting for those to take effect and then will test again once my system has time to stabilize after startup.

Yeah, 1 core (hopped around to different cores along the way) was pegged at 100% during the entire check. I know it's not the fastest CPU out there, but I'd think an i5-4690k would have the muscle to power through. So that was certainly surprising, but I guess I never really paid attention to the CPU usage in the past during a parity check.

OK, it finally finished after 1 day, 4hrs, 41min with 77.5MB/s vs previously consistently at 18hrs, 50min with 118MB/s. That's 10hrs slower (50%) - that's crazy. I have no idea what's gone wrong.

I'll keep waiting, but it's now been the 18hrs 50min that it's been historically and I'm only at 62% complete. Things have sped up slightly (82ish MB/s), but still overall a far way away from previous runs. I can update when it completes, but it seems the original estimate will be pretty close.