Is it better to run RetroArch on just one or various CPUs/cores?

RetroArch Linux devices
#1

Hi there,

I have been doing some experiments with RA without a clear conclussion. On my system, two cores are isolated (isolcpus=2,3) so kernel scheduler doesn’t chose them for system tasks and they are free to be always available for RA. I run RA on those two cores with “taskset -c 2,3”, and according to TOP, that’s where RA runs on. I am not using threaded video or threaded audio: I use dispmanx and alsa as video and audio drivers. However, this is my question: If I only specify one CPU to taskset, RA runs on ONE core/CPU, but if I specify both 2 and 3, it “jumps” between them according to TOP. What’s better for latency in this scenario? One or two CPUs? Also, what scheduler policy is better? I currently use RR (round robin) with RT priority.

Thanks!

#2

one core should be better, I think. Dunno about schedulers.

#3

Hmm… so RA jumping between cores is not good, right?

#4

I don’t know that it’s particularly bad but it’s not good, either. I think modern OSes are pretty good about handing off tasks between cores without causing too many problems, but sticking with a single core all the time takes one more variable out of the equation.

#5

Then I would say that isolating one CPU/core (so the scheduler never choses it) and run RA on that core only seems like a good idea, isn’t it?

#6

Yeah, could be. You’ll probably just need to give a shot and see if it helps/hinders.

#7

The thing is, I have already tried and I can’t see a clear difference: I can’t go under 48ms audio latency with the dispmanx driver (max_swapchain=2) either letting the OS chose or pinning RA to an isolated CPU, so I just wanted to talk about the idea. Not that many people around on my real life enviroment know about these things :smiley:

#8

Ah, gotcha. Yeah, it’s not likely to help much, but it sounds like it doesn’t help at all. Oh well :slight_smile:

#9

@vanfanel To know if it technically makes a difference being on 1 core vs 2, you would need to profile the time spent doing context switches between the cores, versus the extra load (cpu time) of just being on 1 core, to see if the context switching is perhaps costing you more time than the extra core would be saving you in the first place.

Like you’ve noticed, it probably will not make much of a difference unless either the core in question was quite demanding (and multi-threaded), or either your cpu was quite slow otherwise.

Also the OS’es scheduler and your CPU in general is still busy switching between all your other cores doing normal Linux stuff, so that is maybe another reason that you don’t see much difference. Perhaps if you ran such a test with RetroArch being the ONLY process (e.g. boot with init=/foo/retroarch), it’s possible you might be able to measure something.

If your goal is to reduce and/or have more predictable latency, you might also try the -rt kernel patches… which I think Lakka recently switched to using (not sure on which platforms).

Hope this helps.