Serious Sam 3: BFE > Discussões Gerais > Detalhes do Tópico
avi9526 8 Mar, 2013 às 11:52
Serious Sam 3 use only one CPU
I am running Serious Sam 3 on linux (Ubuntu 12.10).
The problem is that Sam3 uses only one of my 4 CPU's all the time - CPU0.
It won't switch to others CPU's. Using Sam3 process PID and command "taskset" I found that
taskset -p 7160
pid 7160's current affinity mask: 1
Seems, that CPU-affinity set to only one CPU0. Why that was done?

Я запускаю Serious Sam 3 на linux (Ubuntu 12.10).
Проблема в том, что Sam3 всё время использует только одно и то же ядро (CPU0). С помощью комманды taskset обнаружил что
taskset -p 7160
pid 7160's current affinity mask: 1
пролучается что игра привязана только к одному ядру. Вопрос: нафига?
A mostrar 1-9 de 9 comentários
< >
kwahoo 8 Mar, 2013 às 13:27 
avi9526 8 Mar, 2013 às 14:59 
Thnx for response. I know about this commands. But the problem still appear (of course less). Let me explain it more detailed to make it clear:

Normally if some program use only one CPU, its switch by OS to another CPU after some time, so every CPU used and CPU chip heated evenly.

Sam3 use one core CPU0 and don't want switch to another CPU. It's cause that core CPU0 is working all time at ~80..100% load while other CPU's (In my case CPU1..CPU3) is low-loaded at ~10..30%.

Even if I enable multicore rendering - Sam3 use one and same core CPU0. Because OS parameter called CPU-affinity set to 0x0001, while for other processes its 0x000F

mpstat 1 300 -P ALL
give CPU usage after 300 seconds of monitoring:

CPU %idle
all 50.13
0 17.59
1 55.94
2 63.19
3 64.48

As You can see, most of all CPU's in this 300 seconds works CPU0 (less idle percentage).

To make Sam3 use all cores evenly I need call command
taskset -p f $PID
where $PID - ID of Sam3 process; f - hexadecimal number 15.

After doing that (even with mutlicore rendering disabled) I get

CPU %idle
all 59.78
0 54.28
1 63.33
2 66.84
3 54.52

Now, as You can see, all CPU loaded more evenly.

Of course, seems there was some performance decrease (feel like lost ~5 FPS)

So, I interested why this was done? And is there a way to make it permanent?
kwahoo 8 Mar, 2013 às 18:03 
That's intended behavior introduced during Linux beta testing. It resolves performance problems when CnQ is enabled. There are threads (low fps, shuttering, etc.) in the Linux Steam section...

You have a question:
Originalmente postado por avi9526:
So, I interested why this was done?

And you have an answer:
Originalmente postado por avi9526:
Of course, seems there was some performance decrease (feel like lost ~5 FPS)

Check also fps graph to see difference:

Finally - If you have an i5 or i7 CPU check (using i7z) how turbo mode works in both cases.
Última alteração por kwahoo; 8 Mar, 2013 às 18:12
AlenL  [autor] 9 Mar, 2013 às 20:35 
avi, can you please post your Sam3.log file?
avi9526 9 Mar, 2013 às 22:36 

I am using next command to change CPU-affinity mask to 'F':
taskset -p F $(ps ax | awk '/Sam3$/ {print($1)}')

There is screenshot of CPU-load graph with moment of changing affinity mask to F at middle of graph:

Next screenshots shows FPS graph when changing CPU-affinity:
switch CPU-affinity mask from 1 to F -
switch CPU-affinity mask from F to 1 -

Anyway, even assuming FPS drop, am I able to make this CPU-affinity mask permanent for my gameplay?
AlenL  [autor] 10 Mar, 2013 às 6:08 
I think that what you are seeing is not affinity mask for the entire process. The process uses several threads and automatically adapts to presence of multiple CPUs, by creating one worker thread per CPU. This approach works well on Windows and OSX, but on Linux, there are some issues when power saving on the CPU is enabled. See this line in your log:

07:51:00 WRN: CPU Power saving is enabled and performance governor is not used.

We have determined through testing that the "ondemand" governor (which is default, and which you have) seems to have some bugs and causes the erratic behavior that you see on your FPS graph. It appears as if the governor and scheduler interact in a weird way so that governor downclocks less used cores, but then the scheduler moves the main thread to that underclocked core, which the governor then clocks back, etc ad nauseam. We have contacted kernel devs, most notably developers from Intel that are working on that area, but they seem to still be looking into this.

The only workaround that we can come up from application side was to set strict affinity for each thread.

Ultimately, it is best if you switch to using the "performance" governor.

If you want to have the game not lock to threads, then set this cvar:


Note that if you do that without performance governor, you will loose a few FPS as noted above.
avi9526 10 Mar, 2013 às 13:29 
Thanks for support.

But seems that this doen't work
I changed that cvar and restarted a game. thr_iAffinityStrictness still equal to 0 but command
taskset -p $(ps ax | awk '/Sam3$/ {print($1)}')
pid 5119's current affinity mask: 1
AlenL  [autor] 11 Mar, 2013 às 6:08 
Well, if that is so, then it is not our doing. I don't know why that would happen.
AlenL  [autor] 11 Mar, 2013 às 7:02 
Oops, correction. We've found a bug that can cause such behavior. We'll have a fix in the next update.

Nevertheless, if you are going to be using this, then you should definitely switch to using the performance governor.
A mostrar 1-9 de 9 comentários
< >
Por página: 15 30 50
Postado a: 8 Mar, 2013 às 11:52
Comentários: 9