A process CPU usage doesn't change for different priority

I wrote an infinite loop in python to print No! in the output.

while True:
    print("No!")

When I execute it, I see its process (pythonw.exe) in Windows-Task-Manager that uses 60% of the CPU. I did a right-click on its process and change the priority to Low. it use 60% of CPU again! Then I change the priority to Real-Time. It still uses 60% of CPU !

Update: My total CPU usage for all process is 80%!!! and 20% is free! Why this python loop doesn't use this 20%?!

What's wrong with priority? Why it doesn't change?

TheGoodUser

Posted 2014-09-26T16:30:44.077

Reputation: 1 045

1Because the x86 instructions required to do this don't take more than 60% of a single clock cycle – Ramhound – 2014-09-26T16:32:41.440

Would you please explain it more clear as an answer? Why those instructions doesn't take more than 60% of a single clock cycle in x86? is it different in x64? – TheGoodUser – 2014-09-26T16:40:11.523

X64 is an extension of the x86 architecture, what part, don't you understand exactly – Ramhound – 2014-09-26T16:57:29.323

@Ramhound 1- x86 instructions required to do this don't take more than 60% of a single clock cycle. Why?! And 2- Why when I set its priority to Low it still use 60%? Why doesn't it reduces? – TheGoodUser – 2014-09-26T17:06:08.963

Because the load delta caused by this script and the load without the script the processor doesn't have to prioritize the threads. As for the other part unless you know x86 assembly any additional details wouldn't be helpful – Ramhound – 2014-09-26T17:09:45.110

@Ramhound Would you please try me! I know assembly a little :D I may find it helpful! – TheGoodUser – 2014-09-26T17:31:47.413

Feel free to covert that to assembly yourself than to understand what's actually happening – Ramhound – 2014-09-26T17:54:19.953

It is not possible for an instruction to use a fraction of a single clock cycle. An executing program can, however, use only 60% of the total available clock cycles. – Jamie Hanrahan – 2018-12-26T18:39:46.413

Answers

The priority determines which thread gets to run when multiple threads are competing for CPU time. If nothing else wants the CPU, your program's thread(s) will get up to 100% CPU time, as and when needed, regardless of priority.

In your case the Python process is the only one needing a lot of CPU time, so it will get all it asks for. If your system were otherwise busy, then you would see your 60% drop much more than if it had normal priority.

You should test it against another CPU-consuming program running at the same time, eg in a CMD shell run test.cmd containing:

:Loop
dir /s c:\
goto Loop

Then you will see the effects of changing the priority of your competing process. Note that the CPU requirements of this example will vary, depending on the CPU speed, the number of files in c:\ and disc cache sizes; redirecting the dir output to >nul: will increase the CPU load.

AFH

Posted 2014-09-26T16:30:44.077

Reputation: 15 470

this batch file program uses only 3 percent! and again it doesn't change even if I change its priority! for that Python program, its CPU usage is fixed on 60% , while my total CPU usage is 80%! I mean, My CPU has 20% free !!! – TheGoodUser – 2014-09-26T16:51:55.283

You can't force a program to consume more time within a clock cycle than it needs – Ramhound – 2014-09-26T17:00:10.870

@TheGoodUser-Sp - I didn't want to make it too intensive, but if you redirect the output, as in dir /s c:\ >nul:, that will increase the CPU demand. If you comment out the dir line, you will create a CPU loop. – AFH – 2014-09-26T17:10:38.527

1@TheGoodUser-Sp - As an adjunct, it is worth noting that unless other processes require more than 40% CPU, then the 60% your python program demands will always be available. You could also try running two copies of your program and changing the priority of one of them: they can't both get 60%, which guarantees that the CPU will be overstretched, so that priorities will be taken into account in the allocation of the CPU. – AFH – 2014-09-26T18:00:57.293

The dir command is not particularly CPU-intensive - it's disk-bound. – Jamie Hanrahan – 2015-09-04T10:22:00.090

Funny thing, but writing to the console (i.e. a command prompt window) in a character-mode app (like cmd) does not only involve CPU time in the writing process. The character-mode app has no GUI code (User or GDI calls) in it - otherwise it wouldn't be a character-mode app. Writes to stdout (or whatever) are handled by sending messages to another process (like conhost), which runs the window for you. So no, you won't see CPU time only in the process the character-mode app. Running a GUI app that just writes text to its own window is actually more efficient! – Jamie Hanrahan – 2015-09-04T10:27:27.777

@JamieHanrahan - Of course, you are technically correct that it is the threads that consume CPU time, but I'm not sure your update adds anything to my answer, since a program's CPU demand is the total of its threads' demands, and it is this total which is normally displayed by system monitors, such as TaskManager, ProcExp, etc. Point taken about CMD vs GUI applications, but for my illustration I wanted a process with a high CPU demand though not 100%. – AFH – 2015-09-04T11:54:11.183

It may not add much to the answer, but I find that to truly understand Windows scheduling the distinction betwen processes and threads is important. So, might as well use the right term, even when talking about a single-threaded process. Making the distinction certainly doesn't hurt the answer and may help head off confusion in the future. – Jamie Hanrahan – 2015-09-04T12:08:01.860

@AFH The "Windows Internals Book Tools" - sort of an adjunct to the sysinternals tools - include a fun little thing called cpustres that you can use to create from one to four threads that busy the CPU settable portins of time, from about 25% to 100%. cpustres is used in many of the "experiments" in the scheduling chapter of Windows Internals. https://technet.microsoft.com/en-us/sysinternals/bb963901.aspx?f=255&MSPPError=-2147217396

– Jamie Hanrahan – 2015-09-04T12:14:55.720

There's nothing wrong with priority.

It is a common assumption that a low or medium priority set on a process will cause the operating system to limit the CPU time available to the process's threads - so, setting its priority higher should let it use more CPU!

But that is not what happens.

You can have a process set to the lowest possible priority, and if its code never needs to wait for anything, and if nothing else on the system wants CPU time, that process will get 100% of the CPU.

If a process gets less than 100% CPU, and nothing of equal or higher priority is trying to run, then that simply means that the process's threads are spending part of their time not wanting the CPU.

What is a thread doing if it doesn't want the CPU? Most of the time it's "waiting". Threads wait when they need something to happen that doesn't involve running the thread's own code in the CPU. Usually they're waiting for an I/O operation to complete. This could be an I/O request explicitly requested by the thread, or it could be, for example, a hard page fault. (On the other hand, time spent "waiting" for RAM read or write latency is all part of the thread's CPU time. That's not considered I/O.)

Your loop in Python includes a "print" funciton. That's an I/O operation, even if it's only to the screen.

You could use Windows Performance Analyzer to get details about just what pythonw.exe is doing that's making it wait.

You may wish to review my answer here.

Jamie Hanrahan

Posted 2014-09-26T16:30:44.077

Reputation: 19 777