http://bugzilla.suse.com/show_bug.cgi?id=1131437 http://bugzilla.suse.com/show_bug.cgi?id=1131437#c15 --- Comment #15 from Giovanni Gherdovich <giovanni.gherdovich@suse.com> --- Created attachment 802894 --> http://bugzilla.suse.com/attachment.cgi?id=802894&action=edit 2-clients dbench data from 5.0 versus the SLE-15-SP1 kernel I've looked at the 2-clients case ignoring the rest. To me it looks like the problem in mainline 5.0 (booted with security mitigation disabled) is that only one client can go fast, but not both at the same time. I'm attaching a plot that shows that. Sometime the fast/slow roles switch mid-test, see for example the mainline-4 plot in my figure. Jan already showed that frequency scaling plays a role here; I'll try to find what's the event or situation that makes one client go fast but not the other. Jan discovery that setting governor=performance and max_cstate=1 fixes the problem means that the key to solve this are on-cpu events, as opposed to what happens off-cpu (waiting for stuff) -- that should make it slightly easier to see on the traces. For that I'll need to identify and trace the IO thread (which I guess it's called dbench-something) and the XFS journaling thread, as Jan once explained me these are the ones that get the work done. Once I know on which cpu those are, I can correlate to frequency changes from turbostat with a sampling rate like 500 ms or so. Something comforting about the diagram I'm attaching here is that the phenomenon is rather macroscopic, meaning coarse sampling with turbostat can be used: a dbench client can be fast or slow, but it stays like that for a long period of time (seconds). -- You are receiving this mail because: You are on the CC list for the bug.