Thread (7 messages) flat view 7 messages, 3 authors, 2011-03-16

Re: [PATCH, v9 3/3] cgroups: introduce timer slack controller

From: Andrew Morton <hidden>
Date: 2011-03-14 23:47:41
Also in: lkml

On Mon, 14 Mar 2011 16:05:24 +0200
Kirill A. Shutemov" [off-list ref] wrote:
+Overview
+--------
+
+Every task_struct has timer_slack_ns value. This value uses to round up
+poll() and select() timeout values. This feature can be useful in
+mobile environment where combined wakeups are desired.
+
+Originally, prctl() was the only way to change timer slack value of
+a process. So you was not able change timer slack value of another
+process.
+
+cgroup subsys "timer_slack" implements timer slack controller. It
+provides a way to set minimal timer slack value for a group of tasks.
+If a task belongs to a cgroup with minimal timer slack value higher than
+task's value, cgroup's value will be applied.
+
+Timer slack controller allows to implement setting timer slack value of
+a process based on a policy. For example, you can create foreground and
+background cgroups and move tasks between them based on system state.
(quoting myself from last time)

Why do we need a cgroup for this as opposed to (say) inheritance over
fork(), or a system-wide knob, or a per-process/threadgroup knob, or
just leaving the existing code as-is?  Presumably you felt that a
cgroup approach is better for manageability, but you didn't tell us
about this and you didn't explore alternative ways of solving the
problem-which-you-didn't-describe.




I'm still having trouble seeing why we should merge this.  Who will use
it, and for what reason and what benefits will they see?  Quantified
benefits, if possible!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help