Difference between nice level and systemctl CPUShares property
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
As I understand it (please correct me if I'm wrong),
systemctl set-property ... CPUShares=some_value
limits the cpu time for an entire cgroup unit. If we instead want to limit cpu time for a process within that unit, we can run the process with
systemd-run ... nice=some_value
I'm wondering if there's some intrinsic difference between the concepts of the nice-value of a process and the CPUShares-value of a group of processes? Can we limit CPUShares of a process, or set the nice-value of a cgroup unit? When would we want to do one or the other?
systemd cgroups nice
asked Feb 14 '17 at 15:28
embedded_crysisembedded_crysis
775
add a comment |
As I understand it (please correct me if I'm wrong),
systemctl set-property ... CPUShares=some_value
limits the cpu time for an entire cgroup unit. If we instead want to limit cpu time for a process within that unit, we can run the process with
systemd-run ... nice=some_value
I'm wondering if there's some intrinsic difference between the concepts of the nice-value of a process and the CPUShares-value of a group of processes? Can we limit CPUShares of a process, or set the nice-value of a cgroup unit? When would we want to do one or the other?
systemd cgroups nice
asked Feb 14 '17 at 15:28
embedded_crysisembedded_crysis
775
add a comment |
As I understand it (please correct me if I'm wrong),
systemctl set-property ... CPUShares=some_value
limits the cpu time for an entire cgroup unit. If we instead want to limit cpu time for a process within that unit, we can run the process with
systemd-run ... nice=some_value
I'm wondering if there's some intrinsic difference between the concepts of the nice-value of a process and the CPUShares-value of a group of processes? Can we limit CPUShares of a process, or set the nice-value of a cgroup unit? When would we want to do one or the other?
systemd cgroups nice
asked Feb 14 '17 at 15:28
embedded_crysisembedded_crysis
775
As I understand it (please correct me if I'm wrong),
systemctl set-property ... CPUShares=some_value
limits the cpu time for an entire cgroup unit. If we instead want to limit cpu time for a process within that unit, we can run the process with
systemd-run ... nice=some_value
I'm wondering if there's some intrinsic difference between the concepts of the nice-value of a process and the CPUShares-value of a group of processes? Can we limit CPUShares of a process, or set the nice-value of a cgroup unit? When would we want to do one or the other?
systemd cgroups nice
systemd cgroups nice
asked Feb 14 '17 at 15:28
embedded_crysisembedded_crysis
775
asked Feb 14 '17 at 15:28
embedded_crysisembedded_crysis
775
asked Feb 14 '17 at 15:28
embedded_crysisembedded_crysis
775
asked Feb 14 '17 at 15:28
embedded_crysisembedded_crysis
775
asked Feb 14 '17 at 15:28
embedded_crysisembedded_crysis
775
775
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
From reading man systemd-run, it will create a service and thus a cgroup on the fly. From reading systemd.exec, the Nice= directive will apply to all executed processes, so the way that systmd handles the concepts of Nice= and CPUShares= are very similar.
My understanding of the relationship is that it has to do with history. nice has existed for a listed a couple of decades and always applied to specific processes.
On the other hand, the concept of cgroups and the idea of applying CPUShares= to a process group is much a newer concept but accomplishes the same goal.
I expect systemd supports Nice= for historical compatibility.
I would use whichever one you are comfortable with, but not both to avoid confusion. If you have no preference, I would use the newer CPUShares= concept.
answered Feb 14 '17 at 16:08
Mark StosbergMark Stosberg
4,0681226
1
Beware, using CPU shares and nice values are likely to result in very different behaviors on "recent" distributions using systemd default cgroups (Debian 9 is one of those). Seesched(7): "Under group scheduling, a thread's nice value has an effect for scheduling decisions only relative to other threads in the same task group." A cgroup being such a task group. See my answer for more details.
– Totor
Mar 14 at 13:28
add a comment |
On Linux,
- a nice value applies to a task, that is a process or thread (see link for disambiguation),
- a "CPU shares" value applies to a cgroup (a group of one or more tasks).
The default non-realtime Linux' task scheduler (CFQ), distributes CPU time "fairly" among the different cgroups. It will use the cpu.shares value of each cgroup (by default 1024), relative to other cgroups' cpu.shares values, to grant more or less CPU time to each cgroup (more shares = more CPU bandwith).
Now, within each cgroup, a task's nice value will be used to grant it more or less CPU time, relative to other tasks' nice values within the same cgroup.
sched(7) says:
Under group scheduling, a thread's nice value has an effect for scheduling decisions only relative to other threads in the same task group.
Side notes:
- a task group is a cgroup or an autogroup (see sched(7)),
- autogrouping may be disabled by defaut on your Linux distribution, check with
cat /proc/sys/kernel/sched_autogroup_enabled, - task groups can have hierarchical relationships (cgroups within a cgroup) that I guess the CFQ task scheduler considers to distribute CPU time,
- "recent" distributions may be using systemd to put tasks in cgroups by default (try
systemd-cgtopandsystemd-cgls).
answered Mar 14 at 13:18
TotorTotor
8,807135281
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f344936%2fdifference-between-nice-level-and-systemctl-cpushares-property%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
From reading man systemd-run, it will create a service and thus a cgroup on the fly. From reading systemd.exec, the Nice= directive will apply to all executed processes, so the way that systmd handles the concepts of Nice= and CPUShares= are very similar.
My understanding of the relationship is that it has to do with history. nice has existed for a listed a couple of decades and always applied to specific processes.
On the other hand, the concept of cgroups and the idea of applying CPUShares= to a process group is much a newer concept but accomplishes the same goal.
I expect systemd supports Nice= for historical compatibility.
I would use whichever one you are comfortable with, but not both to avoid confusion. If you have no preference, I would use the newer CPUShares= concept.
answered Feb 14 '17 at 16:08
Mark StosbergMark Stosberg
4,0681226
1
Beware, using CPU shares and nice values are likely to result in very different behaviors on "recent" distributions using systemd default cgroups (Debian 9 is one of those). Seesched(7): "Under group scheduling, a thread's nice value has an effect for scheduling decisions only relative to other threads in the same task group." A cgroup being such a task group. See my answer for more details.
– Totor
Mar 14 at 13:28
add a comment |
From reading man systemd-run, it will create a service and thus a cgroup on the fly. From reading systemd.exec, the Nice= directive will apply to all executed processes, so the way that systmd handles the concepts of Nice= and CPUShares= are very similar.
My understanding of the relationship is that it has to do with history. nice has existed for a listed a couple of decades and always applied to specific processes.
On the other hand, the concept of cgroups and the idea of applying CPUShares= to a process group is much a newer concept but accomplishes the same goal.
I expect systemd supports Nice= for historical compatibility.
I would use whichever one you are comfortable with, but not both to avoid confusion. If you have no preference, I would use the newer CPUShares= concept.
answered Feb 14 '17 at 16:08
Mark StosbergMark Stosberg
4,0681226
1
Beware, using CPU shares and nice values are likely to result in very different behaviors on "recent" distributions using systemd default cgroups (Debian 9 is one of those). Seesched(7): "Under group scheduling, a thread's nice value has an effect for scheduling decisions only relative to other threads in the same task group." A cgroup being such a task group. See my answer for more details.
– Totor
Mar 14 at 13:28
add a comment |
From reading man systemd-run, it will create a service and thus a cgroup on the fly. From reading systemd.exec, the Nice= directive will apply to all executed processes, so the way that systmd handles the concepts of Nice= and CPUShares= are very similar.
My understanding of the relationship is that it has to do with history. nice has existed for a listed a couple of decades and always applied to specific processes.
On the other hand, the concept of cgroups and the idea of applying CPUShares= to a process group is much a newer concept but accomplishes the same goal.
I expect systemd supports Nice= for historical compatibility.
I would use whichever one you are comfortable with, but not both to avoid confusion. If you have no preference, I would use the newer CPUShares= concept.
answered Feb 14 '17 at 16:08
Mark StosbergMark Stosberg
4,0681226
From reading man systemd-run, it will create a service and thus a cgroup on the fly. From reading systemd.exec, the Nice= directive will apply to all executed processes, so the way that systmd handles the concepts of Nice= and CPUShares= are very similar.
My understanding of the relationship is that it has to do with history. nice has existed for a listed a couple of decades and always applied to specific processes.
On the other hand, the concept of cgroups and the idea of applying CPUShares= to a process group is much a newer concept but accomplishes the same goal.
I expect systemd supports Nice= for historical compatibility.
I would use whichever one you are comfortable with, but not both to avoid confusion. If you have no preference, I would use the newer CPUShares= concept.
answered Feb 14 '17 at 16:08
Mark StosbergMark Stosberg
4,0681226
answered Feb 14 '17 at 16:08
Mark StosbergMark Stosberg
4,0681226
answered Feb 14 '17 at 16:08
Mark StosbergMark Stosberg
4,0681226
answered Feb 14 '17 at 16:08
Mark StosbergMark Stosberg
4,0681226
4,0681226
1
Beware, using CPU shares and nice values are likely to result in very different behaviors on "recent" distributions using systemd default cgroups (Debian 9 is one of those). Seesched(7): "Under group scheduling, a thread's nice value has an effect for scheduling decisions only relative to other threads in the same task group." A cgroup being such a task group. See my answer for more details.
– Totor
Mar 14 at 13:28
add a comment |
1
Beware, using CPU shares and nice values are likely to result in very different behaviors on "recent" distributions using systemd default cgroups (Debian 9 is one of those). Seesched(7): "Under group scheduling, a thread's nice value has an effect for scheduling decisions only relative to other threads in the same task group." A cgroup being such a task group. See my answer for more details.
– Totor
Mar 14 at 13:28
1
1
Beware, using CPU shares and nice values are likely to result in very different behaviors on "recent" distributions using systemd default cgroups (Debian 9 is one of those). See
sched(7) : "Under group scheduling, a thread's nice value has an effect for scheduling decisions only relative to other threads in the same task group." A cgroup being such a task group. See my answer for more details.– Totor
Mar 14 at 13:28
Beware, using CPU shares and nice values are likely to result in very different behaviors on "recent" distributions using systemd default cgroups (Debian 9 is one of those). See
sched(7) : "Under group scheduling, a thread's nice value has an effect for scheduling decisions only relative to other threads in the same task group." A cgroup being such a task group. See my answer for more details.– Totor
Mar 14 at 13:28
add a comment |
On Linux,
- a nice value applies to a task, that is a process or thread (see link for disambiguation),
- a "CPU shares" value applies to a cgroup (a group of one or more tasks).
The default non-realtime Linux' task scheduler (CFQ), distributes CPU time "fairly" among the different cgroups. It will use the cpu.shares value of each cgroup (by default 1024), relative to other cgroups' cpu.shares values, to grant more or less CPU time to each cgroup (more shares = more CPU bandwith).
Now, within each cgroup, a task's nice value will be used to grant it more or less CPU time, relative to other tasks' nice values within the same cgroup.
sched(7) says:
Under group scheduling, a thread's nice value has an effect for scheduling decisions only relative to other threads in the same task group.
Side notes:
- a task group is a cgroup or an autogroup (see sched(7)),
- autogrouping may be disabled by defaut on your Linux distribution, check with
cat /proc/sys/kernel/sched_autogroup_enabled, - task groups can have hierarchical relationships (cgroups within a cgroup) that I guess the CFQ task scheduler considers to distribute CPU time,
- "recent" distributions may be using systemd to put tasks in cgroups by default (try
systemd-cgtopandsystemd-cgls).
answered Mar 14 at 13:18
TotorTotor
8,807135281
add a comment |
On Linux,
- a nice value applies to a task, that is a process or thread (see link for disambiguation),
- a "CPU shares" value applies to a cgroup (a group of one or more tasks).
The default non-realtime Linux' task scheduler (CFQ), distributes CPU time "fairly" among the different cgroups. It will use the cpu.shares value of each cgroup (by default 1024), relative to other cgroups' cpu.shares values, to grant more or less CPU time to each cgroup (more shares = more CPU bandwith).
Now, within each cgroup, a task's nice value will be used to grant it more or less CPU time, relative to other tasks' nice values within the same cgroup.
sched(7) says:
Under group scheduling, a thread's nice value has an effect for scheduling decisions only relative to other threads in the same task group.
Side notes:
- a task group is a cgroup or an autogroup (see sched(7)),
- autogrouping may be disabled by defaut on your Linux distribution, check with
cat /proc/sys/kernel/sched_autogroup_enabled, - task groups can have hierarchical relationships (cgroups within a cgroup) that I guess the CFQ task scheduler considers to distribute CPU time,
- "recent" distributions may be using systemd to put tasks in cgroups by default (try
systemd-cgtopandsystemd-cgls).
answered Mar 14 at 13:18
TotorTotor
8,807135281
add a comment |
On Linux,
- a nice value applies to a task, that is a process or thread (see link for disambiguation),
- a "CPU shares" value applies to a cgroup (a group of one or more tasks).
The default non-realtime Linux' task scheduler (CFQ), distributes CPU time "fairly" among the different cgroups. It will use the cpu.shares value of each cgroup (by default 1024), relative to other cgroups' cpu.shares values, to grant more or less CPU time to each cgroup (more shares = more CPU bandwith).
Now, within each cgroup, a task's nice value will be used to grant it more or less CPU time, relative to other tasks' nice values within the same cgroup.
sched(7) says:
Under group scheduling, a thread's nice value has an effect for scheduling decisions only relative to other threads in the same task group.
Side notes:
- a task group is a cgroup or an autogroup (see sched(7)),
- autogrouping may be disabled by defaut on your Linux distribution, check with
cat /proc/sys/kernel/sched_autogroup_enabled, - task groups can have hierarchical relationships (cgroups within a cgroup) that I guess the CFQ task scheduler considers to distribute CPU time,
- "recent" distributions may be using systemd to put tasks in cgroups by default (try
systemd-cgtopandsystemd-cgls).
answered Mar 14 at 13:18
TotorTotor
8,807135281
On Linux,
- a nice value applies to a task, that is a process or thread (see link for disambiguation),
- a "CPU shares" value applies to a cgroup (a group of one or more tasks).
The default non-realtime Linux' task scheduler (CFQ), distributes CPU time "fairly" among the different cgroups. It will use the cpu.shares value of each cgroup (by default 1024), relative to other cgroups' cpu.shares values, to grant more or less CPU time to each cgroup (more shares = more CPU bandwith).
Now, within each cgroup, a task's nice value will be used to grant it more or less CPU time, relative to other tasks' nice values within the same cgroup.
sched(7) says:
Under group scheduling, a thread's nice value has an effect for scheduling decisions only relative to other threads in the same task group.
Side notes:
- a task group is a cgroup or an autogroup (see sched(7)),
- autogrouping may be disabled by defaut on your Linux distribution, check with
cat /proc/sys/kernel/sched_autogroup_enabled, - task groups can have hierarchical relationships (cgroups within a cgroup) that I guess the CFQ task scheduler considers to distribute CPU time,
- "recent" distributions may be using systemd to put tasks in cgroups by default (try
systemd-cgtopandsystemd-cgls).
answered Mar 14 at 13:18
TotorTotor
8,807135281
answered Mar 14 at 13:18
TotorTotor
8,807135281
answered Mar 14 at 13:18
TotorTotor
8,807135281
answered Mar 14 at 13:18
TotorTotor
8,807135281
8,807135281
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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%2funix.stackexchange.com%2fquestions%2f344936%2fdifference-between-nice-level-and-systemctl-cpushares-property%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
