-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add new generate options for setting cpu/mem #175
Conversation
@mrunalp , PTAL. |
The test command is here:
|
@@ -234,6 +234,45 @@ inside of the container. | |||
The special *PATH* `host` removes any existing UTS namespace from | |||
the configuration. | |||
|
|||
**--cpu-shares**=CPUSHARES | |||
Sets the CPU shares (relative weight (ratio) vs. other cgroups with cpu shares). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of having two descriptions to discuss, I'd rather just copy the runtime-spec wording verbatim here. For this setting, that's:
Specifies a relative share of CPU time available to the tasks in a cgroup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wking , thanks for pointing out.
In fact, the current description I am using is from https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc1/specs-go/config.go#L272 .
Is there any plan on runtime-spec side to sync the descriptions on the config-linux.md and config.go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Tue, Aug 02, 2016 at 12:28:18PM -0700, hmeng-19 wrote:
In fact, the current description I am using is from
https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc1/specs-go/config.go#L272
. Is there any plan on runtime-spec side to sync the descriptions
on the config-linux.md and config.go?
Heh. I'm not aware of a plan, but I'll file a PR updating the Go
comments this evening if nobody beats me to it. And if you feel moved
to PR the update, don't wait for me ;).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wking , go ahead with the runtime-spec PR to fix it.
On Tue, Aug 02, 2016 at 12:00:25PM -0700, hmeng-19 wrote:
As ‘ocitools generate’ grows, it's probalby worth adding a |
1fd83a3
to
71a9fea
Compare
@@ -234,6 +234,45 @@ inside of the container. | |||
The special *PATH* `host` removes any existing UTS namespace from | |||
the configuration. | |||
|
|||
**--cpu-shares**=CPUSHARES |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Options in this man page are currently alphabetized (since #44). That's an easier pattern to follow than grouping related options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wking , will fix it. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be worth using --linux-cpu-shares
here to leave room for other platforms with their own interpretation of CPU shares. That will help avoid confusion when someone PRs --solaris-ncpus
, etc. It's possible that there is common ground here and we could have a cross-platform --cpu-shares
option, but if that's the case I'd rather have runtime-spec leading the push towards unification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mrunalp , how to think about this?
@wking 👍 to a test harness. I don't care what it is as long as we have something 😉 |
71a9fea
to
8ff81a1
Compare
The new test command is:
|
Needs rebase? |
8ff81a1
to
b812c1b
Compare
@mrunalp , rebased it. PTAL. |
Sets the limit of memory usage in bytes. | ||
|
||
**--linux-mem-reservation**=MEMRESERVATION | ||
sets the soft limit of memory usage in bytes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
“sets” → “Sets”
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed it.
b812c1b
to
84d9c19
Compare
Specifies a relative share of CPU time available to the tasks in a cgroup. | ||
|
||
**--linux-cpu-period**=CPUPERIOD | ||
Specifies a period of time in microseconds for how regularly a cgroup's access to CPU resources should be reallocated (CFS scheduler only). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
“CFS only” seems like we want a --host-specific
guard to error out if someone tries to set it with --host-specific
when they aren't using a CFS scheduler. But after reading over sched(7) and sched_setscheduler(2), I'm not quite sure how to do that. It looks like you check for a SCHED_OTHER
policy
, but sched_getscheduler
is per-thread. Is the scheduler policy really set on a per-thread basis? Is a host-specific check just supposed to look for internal consistency (e.g. the config doesn't set both a CFS-only and a realtime-only parameter)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wking , I think there are two ways we can use to determine the current scheduler.
- Read the kernel config file, refer to https://en.wikipedia.org/wiki/Completely_Fair_Scheduler:
[hmeng@localhost boot]$ grep CONFIG_SCHED_AUTOGROUP /boot/config-4.6.4-201.fc23.x86_64
CONFIG_SCHED_AUTOGROUP=y
- check the /sys/fs/cgroup/cpu dir to see whether
cpu.cfs_period_us
exists or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Fri, Aug 05, 2016 at 11:58:48AM -0700, hmeng-19 wrote:
@wking , I think there are two ways we can use to determine the current scheduler.
- Read the kernel config file, refer to https://en.wikipedia.org/wiki/Completely_Fair_Scheduler:
[hmeng@localhost boot]$ grep CONFIG_SCHED_AUTOGROUP /boot/config-4.6.4-201.fc23.x86_64 CONFIG_SCHED_AUTOGROUP=y
- check the /sys/fs/cgroup/cpu dir to see whether
cpu.cfs_period_us
exists or not.
These both sound like “does your kernel support that scheduler”, but
if scheduler policy is per-thread, then how do you know the container
will use that available scheduler (and not another available
scheduler)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Fri, Aug 05, 2016 at 08:25:27PM -0700, hmeng-19 wrote:
+--linux-cpu-period=CPUPERIOD
- Specifies a period of time in microseconds for how regularly a cgroup's access to CPU resources should be reallocated (CFS scheduler only).
@wking , @mrunalp , do correct me if I am wrong.
I always thought the scheduling policy is a system-level config. It
is decided when you built your kernel. Right?
That was my impression before poking around in the man pages today.
But see also 1, which has:
Each process or thread is controlled by an associated scheduling
policy and priority…
And 2 has:
If at least one RT task is running, no other SCHED_OTHER task will
be allowed to run in any CPU.
which makes it fairly clear that you can have threads/processes with
different schedulers running concurrently. I'm not sure how that
works for the cgroup settings though. Maybe you can set them all
(both real-time and CFS parameters) and the kernel will apply the
appropriate limits to each task depending on its policy? In that
case, configs that specify settings for multiple schedulers are fair
game.
LGTM |
@hmeng-19 seems need rebase |
Signed-off-by: Haiyan Meng <[email protected]>
84d9c19
to
092cb7c
Compare
@Mashimiao , @mrunalp , PTAL. |
LGTM |
Signed-off-by: Haiyan Meng <[email protected]> Backported to v1.0.0.rc1 from 092cb7c opencontainers#175 (cherry-pick applied cleanly). Signed-off-by: W. Trevor King <[email protected]>
Signed-off-by: Haiyan Meng [email protected]