Is process priority periodically recalculated by OS?
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.
windows-7 windows process priority
add a comment |
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.
windows-7 windows process priority
add a comment |
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.
windows-7 windows process priority
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.
windows-7 windows process priority
windows-7 windows process priority
asked Jul 20 '16 at 11:08
tom.wolanskitom.wolanski
161
161
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
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?
Thank you for this answer. Yep, is known that changing priority is programmatically possible, but this is does not solve initial problem. Also, yep, is could be related to VS, but, same configuration on another machine works well. So, I cant give you a bounty because you answer doesn't solve initial problem.
– tym32167
Oct 10 '16 at 9:39
add a comment |
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.
add a comment |
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.
add a comment |
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.
This answer does not solve initial problem, but at least explains, why it happens. Thank you.
– tym32167
Oct 11 '16 at 14:26
Sorry, but this answer is contrary to fact in several ways. 1) Threads receive boosted, not lowered, priority after completing a disk IO, the rationale being that letting an I/O bound thread get into the CPU and start its next IO can avoid dead time on the device. 2) Higher priority doesn't mean you "wake up more often"! It means that when you "wake up" (that is, go from Wait to Ready state) you get to use the CPU before lower-priority Ready threads do. 3) While a thread is blocked on a disk IO (or any other IO) it doesn't "wake up" at all! That's what "blocked on disk IO" means.
– Jamie Hanrahan
Dec 29 '18 at 23:19
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1103111%2fis-process-priority-periodically-recalculated-by-os%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
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?
Thank you for this answer. Yep, is known that changing priority is programmatically possible, but this is does not solve initial problem. Also, yep, is could be related to VS, but, same configuration on another machine works well. So, I cant give you a bounty because you answer doesn't solve initial problem.
– tym32167
Oct 10 '16 at 9:39
add a comment |
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?
Thank you for this answer. Yep, is known that changing priority is programmatically possible, but this is does not solve initial problem. Also, yep, is could be related to VS, but, same configuration on another machine works well. So, I cant give you a bounty because you answer doesn't solve initial problem.
– tym32167
Oct 10 '16 at 9:39
add a comment |
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?
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?
answered Oct 4 '16 at 15:20
KeltariKeltari
51k18118170
51k18118170
Thank you for this answer. Yep, is known that changing priority is programmatically possible, but this is does not solve initial problem. Also, yep, is could be related to VS, but, same configuration on another machine works well. So, I cant give you a bounty because you answer doesn't solve initial problem.
– tym32167
Oct 10 '16 at 9:39
add a comment |
Thank you for this answer. Yep, is known that changing priority is programmatically possible, but this is does not solve initial problem. Also, yep, is could be related to VS, but, same configuration on another machine works well. So, I cant give you a bounty because you answer doesn't solve initial problem.
– tym32167
Oct 10 '16 at 9:39
Thank you for this answer. Yep, is known that changing priority is programmatically possible, but this is does not solve initial problem. Also, yep, is could be related to VS, but, same configuration on another machine works well. So, I cant give you a bounty because you answer doesn't solve initial problem.
– tym32167
Oct 10 '16 at 9:39
Thank you for this answer. Yep, is known that changing priority is programmatically possible, but this is does not solve initial problem. Also, yep, is could be related to VS, but, same configuration on another machine works well. So, I cant give you a bounty because you answer doesn't solve initial problem.
– tym32167
Oct 10 '16 at 9:39
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Dec 7 '17 at 16:01
jan-glxjan-glx
219210
219210
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Dec 29 '18 at 23:15
answered Dec 22 '18 at 23:08
Jamie HanrahanJamie Hanrahan
18.2k34279
18.2k34279
add a comment |
add a comment |
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.
This answer does not solve initial problem, but at least explains, why it happens. Thank you.
– tym32167
Oct 11 '16 at 14:26
Sorry, but this answer is contrary to fact in several ways. 1) Threads receive boosted, not lowered, priority after completing a disk IO, the rationale being that letting an I/O bound thread get into the CPU and start its next IO can avoid dead time on the device. 2) Higher priority doesn't mean you "wake up more often"! It means that when you "wake up" (that is, go from Wait to Ready state) you get to use the CPU before lower-priority Ready threads do. 3) While a thread is blocked on a disk IO (or any other IO) it doesn't "wake up" at all! That's what "blocked on disk IO" means.
– Jamie Hanrahan
Dec 29 '18 at 23:19
add a comment |
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.
This answer does not solve initial problem, but at least explains, why it happens. Thank you.
– tym32167
Oct 11 '16 at 14:26
Sorry, but this answer is contrary to fact in several ways. 1) Threads receive boosted, not lowered, priority after completing a disk IO, the rationale being that letting an I/O bound thread get into the CPU and start its next IO can avoid dead time on the device. 2) Higher priority doesn't mean you "wake up more often"! It means that when you "wake up" (that is, go from Wait to Ready state) you get to use the CPU before lower-priority Ready threads do. 3) While a thread is blocked on a disk IO (or any other IO) it doesn't "wake up" at all! That's what "blocked on disk IO" means.
– Jamie Hanrahan
Dec 29 '18 at 23:19
add a comment |
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.
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.
edited Oct 11 '16 at 1:51
answered Oct 11 '16 at 1:42
panos415panos415
35813
35813
This answer does not solve initial problem, but at least explains, why it happens. Thank you.
– tym32167
Oct 11 '16 at 14:26
Sorry, but this answer is contrary to fact in several ways. 1) Threads receive boosted, not lowered, priority after completing a disk IO, the rationale being that letting an I/O bound thread get into the CPU and start its next IO can avoid dead time on the device. 2) Higher priority doesn't mean you "wake up more often"! It means that when you "wake up" (that is, go from Wait to Ready state) you get to use the CPU before lower-priority Ready threads do. 3) While a thread is blocked on a disk IO (or any other IO) it doesn't "wake up" at all! That's what "blocked on disk IO" means.
– Jamie Hanrahan
Dec 29 '18 at 23:19
add a comment |
This answer does not solve initial problem, but at least explains, why it happens. Thank you.
– tym32167
Oct 11 '16 at 14:26
Sorry, but this answer is contrary to fact in several ways. 1) Threads receive boosted, not lowered, priority after completing a disk IO, the rationale being that letting an I/O bound thread get into the CPU and start its next IO can avoid dead time on the device. 2) Higher priority doesn't mean you "wake up more often"! It means that when you "wake up" (that is, go from Wait to Ready state) you get to use the CPU before lower-priority Ready threads do. 3) While a thread is blocked on a disk IO (or any other IO) it doesn't "wake up" at all! That's what "blocked on disk IO" means.
– Jamie Hanrahan
Dec 29 '18 at 23:19
This answer does not solve initial problem, but at least explains, why it happens. Thank you.
– tym32167
Oct 11 '16 at 14:26
This answer does not solve initial problem, but at least explains, why it happens. Thank you.
– tym32167
Oct 11 '16 at 14:26
Sorry, but this answer is contrary to fact in several ways. 1) Threads receive boosted, not lowered, priority after completing a disk IO, the rationale being that letting an I/O bound thread get into the CPU and start its next IO can avoid dead time on the device. 2) Higher priority doesn't mean you "wake up more often"! It means that when you "wake up" (that is, go from Wait to Ready state) you get to use the CPU before lower-priority Ready threads do. 3) While a thread is blocked on a disk IO (or any other IO) it doesn't "wake up" at all! That's what "blocked on disk IO" means.
– Jamie Hanrahan
Dec 29 '18 at 23:19
Sorry, but this answer is contrary to fact in several ways. 1) Threads receive boosted, not lowered, priority after completing a disk IO, the rationale being that letting an I/O bound thread get into the CPU and start its next IO can avoid dead time on the device. 2) Higher priority doesn't mean you "wake up more often"! It means that when you "wake up" (that is, go from Wait to Ready state) you get to use the CPU before lower-priority Ready threads do. 3) While a thread is blocked on a disk IO (or any other IO) it doesn't "wake up" at all! That's what "blocked on disk IO" means.
– Jamie Hanrahan
Dec 29 '18 at 23:19
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1103111%2fis-process-priority-periodically-recalculated-by-os%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown