Hyper-Threading Performance Problem [Linux]

[silver]

Using Dolphin under linux causes massive performance problems when Hyper-Threading is activated.

I have tested latest dolphin build under (Ubuntu 14.04) with i7-4770k and enabled Hyper-Threading.

The problem here is that the Linux scheduler sometimes assign both dolphin threads to two logical CPU cores which share same physical_id.
As you can see in the attached pictures CPU2 and CPU6 (which are on the same physical core) are both at 100%.
This causes a frame rate drop of ~40% until the assignment changes.
The issue can be fixed by either forcing the task to run on cores with different physical_id or deactivating Hyper-Threading.

I tried to find out why this happens because the linux scheduler should normally be aware of SMT and should avoid those situations!?
Maybe we should let dolphin lock its threads to predefined cores to get around this problem?

[Shonumi]

Dolphin used to have a Lock Threads to Cores option, but this was eliminated quite a bit ago. I think the developer consensus was that it isn't Dolphin's job to do the scheduling. I have never tried Hyperthreading under Linux, but I heard the scheduler was pretty spot on for Dolphin. Might be you need to wait for a kernel update or something. There's probably a way to run a specific program using only certain cores via the command line, some utilities, and scripting, so try looking at that as a solution in the meantime.

If something changed on Dolphin's end (a regression) that sound definitely be fixed, but if not it's up on the Linux kernel to solve it.

[Fiora]

I think "taskset" is what you want; you can use that to mask out all the virtual cores so it only runs on physical ones.

[silver]

Yes, it can be fixed by using "taskset" but this is only a bad workaround. The problem may cause bad user experience under linux for many people so I would like to find out why this happens.
And yes maybe it is a kernel problem but I cannot find any bug reports describing such a behavior. Everyone just say "scheduler is SMT aware and avoid this situation so it will never happen" ..but it happens (at least on my system).
It would be interesting if this problem also affects other people to see if it is really kernel related.

[degasus]

We do have a polling loop within the GPU thread, so maybe the scheduler doesn't detect both threads as full workloads.