On Windows I have frequently changed the priority of a games process to 'high' or 'realtime' to get a performance boost. This has never resulted in any problems with my hardware. I was thinking that maybe I could do this on Linux using the chrt command to change the realtime priority of the games process, as reniceing, even to -20 (the highest priority) doesn't seem to provide any noticeable boost. However, I am wary of doing this without knowing whether it might be bad for my CPU. Can anyone inform me on the risks?

  • 2
    I believe that if any real time process decides to use all available CPU (due to, for example, bugs that leads multiple threads into infinite busy-wait loops), it would remain scheduled on all CPUs to the exclusion of almost everything else. You wouldn't even be able to open a terminal window or SSH in from elsewhere to kill the runaway process(es).
    – Celada
    Commented Jan 1, 2017 at 21:14
  • Any modern OS does a form of time-sharing, so 'priority' simply means they get more time slices than things with lower priority. Anything system-related should always be of the highest priority (think disk I/O and such), so there should be no way to hurt the CPU. Meanwhile, if the game is your only user process then changing the priority won't make much difference anyway.
    – SDsolar
    Commented Jan 2, 2017 at 19:37

3 Answers 3


Changing the priority of a process only determines how often this process will run when other processes are competing for CPU time. It has no impact when the process is the only one using CPU time. A minimum-priority process on an otherwise idle system gets 100% CPU time, same as a maximum-priority process.

So you can run your game with a higher priority, but that won't make it run faster unless something else on the system is using a significant amount of CPU time.

I recommend keeping the priority lower than the X server, because if the X server wants CPU time, it's likely to be because the game is asking it to display something complex, and display is usually a CPU-demanding task (but it depends how much of the work is done in the GPU — CPU priorities have no influence on the GPU).

CPUs are designed to execute code. Changing process priorities won't affect how much work the CPU does, but even if it did, that wouldn't damage the CPU, it would only make it run hotter and so make the fans in the computer blow harder.

  • 10
    There are a lot of things in computer nomenclature, but it still really baffles me that pretty much everyone new to this concept to think "priority" means some kind of "throttle" or "limit". Is the plain English definition ambiguous somehow? If I have priority over you when doing X, and you don't need to do X, then it's as if you didn't exist, right? Why do people get confused over this, do you know?
    – user541686
    Commented Jan 2, 2017 at 4:06
  • 2
    "it would only make it run hotter and so make the fans in the computer blow harder." No, not necessarily. I could have a high-priority process that sits in a tight loop, with memory accesses being serviced from L1 cache, hence little stalling. When the game gets higher priority, it could end up causing less heat because it's stalling the CPU for memory access far more. Priority does not correlate to CPU temperatures, or utilization--it's not a limit as @Mehrdad states.
    – nanofarad
    Commented Jan 2, 2017 at 4:33
  • 2
    @hexafraction, "but even if it did"; nobody stated that it will run hotter
    – Akiiino
    Commented Jan 2, 2017 at 12:09
  • 1
    @hexafraction Does an intel CPU consume less power when it's stalling on a memory access? Not that this has an impact on my answer anyway (the CPU would run hotter if the process was using more CPU time), but AFAIK it's a too short timescale to have a measurable impact on power consumption. Commented Jan 2, 2017 at 12:42
  • 5
    @Mehrdad My guess would be that sometimes people use "top priority" to mean "drop everything you're doing and get this done right now even if it kills you" as opposed to "do this before any non-top priority tasks". Just anthropomorphize the computer a bit and the former starts to make sense, even though the latter is what it really means for computers.
    – Ixrec
    Commented Jan 2, 2017 at 16:21

Are you talking about altering the amount of CPU demand while it's running the thread?

Modern CPU's actually use extremely rapid speed stepping. For example if you did analysis of the clocking of an Intel Core i5/i7 you can see the the clock speeds flickering up and down really really quickly. It's part of the way that Intel can tune the performance relative to amount of power drawn. You might have loads of power available in a desktop PC but the stuff is being converted to heat when the CPU is working harder, so it's important to get the most bang per watt.

I only know this from what I have read on other gaming forums. I'm not a CPU scientist.

I don't think you'd do any damage from tuning a thread to it's maximum "nastyness". The only thing you should keep an eye on is how hot your CPU is getting, but unless you have used overvolting in the BIOS then it's pretty impossible to cook the CPU before it shuts down.

Modern CPU's are designed to rapidly change speed. Do a search for Intel Speed Stepping and 'CPU C states' and you'll see what I mean.


Using renice on a Linux program will not burn up your CPU, but it will not necessarily do what you want it to do.

Priorities have nothing to do with how fast a CPU executes code. It executes code from programs in different priority levels equally fast. What priorities do change is which program the operating system chooses to run when given a choice. CPUs can only run one "thread" of execution at a time (technically 1 per core for multi-core CPUs). If it needs to do more than that, it relies on multitasking - it switches back and forth between executing different programs to give the illusion of running more threads than there are CPUs. When choosing how much time to give to each of these tasks, it does so using the priority as a hint.

What "realtime" means to a computer is less "run this fast" and more "do not preempt this process." Realtime programming is very important in many fields. For example, if I was writing software which manages anti-lock brakes in a car, I really don't want my task to run a few milliseconds late because the OS decided it needed to run a diagnostic on the windshield wipers. Accordingly, the anti-lock brake management software in cars is run at a "real time" priority.

Truthfully, in Linux, the "real time" priority level is a bit of a misnomer. This is because of how Linux schedules its processes. In windows, if you have a process that is running at a higher priority, the processes running at lower priorities are given no CPU time unless the higher priority task is waiting for something -- none at all. Only kernel processes are permitted to run over the top of a "realtime" Windows task. Windows has a ton of bloatware running in the background at all times, so raising the priority to "realtime" prevents all of that junk from running.

However, there's an issue with this. Sometimes your higher priority task is dependent on one of those lower priority tasks. This is called "priority inversion" and it is a big topic in the world of multithreaded programming. When this happens, the higher priority task can starve the lower priority task, not realizing that it is stopping itself! In Linux, this doesn't happen because in Linux, the priorities are viewed as a way to determine what portion of the CPU is given to each program, rather than an all-or-nothing approach. A process running at -20 gets substantially more CPU time than one running at 0, but even in the presence of a -20 program, the 0 program gets some CPU time. If memory serves, the current Linux scheduler gives a program at -1 twice as much CPU power as a 0, and a program at -2 twice as much as a -1, and so forth. This means that 0.9999046% of your CPU time will go to the program that's at -20, but some small fraction does go to the program at 0. The program at 0 will feel like it's running on a 200kHz processor!

If you ever want true real time, where you can prevent anything else from preempting you, you have to write a kernel driver, or you have to use a real-time extension to Linux. Redhat has one called MRG, which permits true real time processing with Linux. In that case "realtime" means something speicific. Under MRG, users in the "realtime" group are permitted to use these real time extensions (which could keep the processor busy forever, because they're intentionally not using the nice friendly Linux scheduler).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .