Argthtjtr

I have a question regarding win-7 schedule and process priority.

The scenario is: I have a process running, initially in priority "Normal"

I find this process to be often reduced to Background (Low I/O). I end up with setting the priority back to "Normal" or "Above Normal", however in few minutes it will be reduced again.

I have tried setting the priority using standard windows task manager or procexp (I guess there should be no difference).

So, the question is: Is process priority recalculated to cover its I/O usage? The process in this situation is Visual Studio 2015, which uses quite a lot HDD, which can be a bottleneck here.

As far as I know, Windows operating systems will not change a process' priority unless told to do so. However, this does not mean a priority cannot be changed by the running program. There is a .NET property called Process.PriorityClass which can change the priority. Perhaps, VS is determining it can reduce its CPU usage to allow other threads more CPU time?

The scheduler of windows will most likely indirectly consider I/O usage (because it will schedule processes less often that return quickly like processes waiting for I/O). However, process priority should be a number set by the user [or other programs (including the process itself)] and influence the scheduler further.
... Enough of the wild guessing of mine.

These answers sugegst using Prio to save a process's priority (enforced by a background service) it might also help in your case.

To my knowledge, Windows does not automatically adjust process priority.

Changing a process's priority sets the "base priority" of all of the threads in the process, and of all threads subsequently created within the process. (See my answer here for a description of this relationship.)

Windows does adjust the priorities of threads based on their recent activity. For example, after a completion of an I/O, a thread's priority will be boosted above its base by an amount determined by the function device driver for the device. Upon every timeslice end, if a thread is running at a boosted priority, its priority will "decay" by 1 until it falls down to the base priority. It does not decay below the base.

This is documented in the chapter on thread scheduling in Windows Internals by Solomon, Russinovich, Ionescu, et al.

But this does not match your reported scenario, because 1) the result of all this boost and decay of thread priority simply does not show up in Task Manager (since Task Manager reports process priority class, not thread priorities); and 2: this mechanism never decays a thread's priority below its base priority. The base is what is set when you change the process priority.

This may be something that Visual Studio (deveng.exe) is doing to itself. Do you see this happening to any other process?

This could be investigated with Windows Performance Toolkit.

Having process priority adjusted in the situation you describe is not unusual.

To simplify things, let's think of the situation this way: higher priority generally means that the process "wakes up" more often than a lower priority process (to perform some work). Considering that your process is doing a lot of (random) disk IO, keeping it at high priority means that it would "wake up" often only to find itself waiting for the disk to return data. Since process switch can be an expensive/time consuming operation, lowering the priority of a disk-intensive process leads to better processor utilization. In other words, by adjusting process priority, the processor can spend more time doing work rather than spending that time switching between processes.

I think it's more likely that VS or the process itself is doing the re-prioritizing.