On Mon, 10 Sep 2007 22:40:49 +0530
Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
+ tg-cfs_rq = kzalloc(sizeof(cfs_rq) * num_possible_cpus(), GFP_KERNEL);
+ if (!tg-cfs_rq)
+ goto err;
+ tg-se = kzalloc(sizeof(se) * num_possible_cpus(), GFP_KERNEL);
+ if (!tg-se)
+
On Tue, Sep 18, 2007 at 05:19:45PM +0900, KAMEZAWA Hiroyuki wrote:
Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
+ tg-cfs_rq = kzalloc(sizeof(cfs_rq) * num_possible_cpus(), GFP_KERNEL);
+ if (!tg-cfs_rq)
+ goto err;
+ tg-se = kzalloc(sizeof(se) * num_possible_cpus(),
* Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Add interface to control cpu bandwidth allocation to task-groups.
btw., just in case it was not obvious, i'll repeat my older assessment
of your patch: the general picture approach looks good to me and the
code is upstream-worthy.
( suggestion:
On Fri, Sep 14, 2007 at 11:41:58AM +0200, Ingo Molnar wrote:
* Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Add interface to control cpu bandwidth allocation to task-groups.
btw., just in case it was not obvious, i'll repeat my older assessment
of your patch: the general picture approach
On Fri, Sep 14, 2007 at 09:29:13PM +0530, Srivatsa Vaddagiri wrote:
2. Enable only one form of grouping, which is task-container based. Provide a
user-space daemon (attached) which can automatically put tasks of
different
Oops ..forgot to attach. But I realize that I had already sent the
On Wed, Sep 12, 2007 at 06:25:37PM +0200, Dmitry Adamushko wrote:
+ kfree(tg);
+}
kfree(tg-cfs_rq) kfree(tg-se) ?
oops, yes!
+ if (tsk-sched_class != fair_sched_class)
+ goto done;
this check should be redundant now with sched_can_attach() in place.
On Tue, Sep 11, 2007 at 11:53:51AM +0200, Dmitry Adamushko wrote:
I guess, 'rq-curr == tsk' implies a task was on the 'rq' (before
dequeueing) in this particular case. What's about a minor optimization
like below (plus, let's make use of task_running()):
Hi Dmitry,
The modified code
On Wed, Sep 12, 2007 at 05:12:02PM +0530, Srivatsa Vaddagiri wrote:
Yes. To emphasise this code doesn't support real-time tasks in a container, I
am returning -ENOTSUP when trying to move a rt-task into a container.
s/ENOTSUP/EINVAL
--
Regards,
vatsa
Paul Menage wrote:
On 9/10/07, Dmitry Adamushko [EMAIL PROTECTED] wrote:
On 10/09/2007, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
objection ;) cpuctlr isn't memorable. Kernel code is write-rarely,
read-often. cpu_controller,
On 11/09/2007, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
[ ... ]
I guess, 'rq-curr == tsk' implies a task was on the 'rq' (before
dequeueing) in this particular case. What's about a minor optimization
like below (plus, let's make use of task_running()):
[ btw., real-time task can be also
On Tue, 11 Sep 2007 09:20:33 +0200 Cedric Le Goater wrote:
Paul Menage wrote:
On 9/10/07, Dmitry Adamushko [EMAIL PROTECTED] wrote:
On 10/09/2007, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
objection ;) cpuctlr isn't
On 9/11/07, Cedric Le Goater [EMAIL PROTECTED] wrote:
And group is more or less implied by the fact that it's in the
containers/control groups filesystem.
control groups is the name of your framework. right ?
That's the main contender for the new name, to replace task
containers since
On Tue, 11 Sep 2007 21:21:19 +0530 Srivatsa Vaddagiri wrote:
On Tue, Sep 11, 2007 at 08:22:43AM -0700, Randy Dunlap wrote:
That looks odd, like it's a filesystem.
What does cfs really mean?
cfs = completely fair scheduler :)
In this thread, we are talking of hooking the cfs cpu
On Sep 10 2007 22:40, Srivatsa Vaddagiri wrote:
+#ifdef CONFIG_FAIR_GROUP_SCHED
+SUBSYS(cpuctlr)
+#endif
cpuctl, cpuctrl, cpu_controller?
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
On Mon, Sep 10, 2007 at 07:05:00PM +0200, Jan Engelhardt wrote:
On Sep 10 2007 22:40, Srivatsa Vaddagiri wrote:
+#ifdef CONFIG_FAIR_GROUP_SCHED
+SUBSYS(cpuctlr)
+#endif
cpuctl, cpuctrl, cpu_controller?
*shrug* .. I used cpuctlr to mean CPU Controller. Any other short names
would do. From
On Mon, 10 Sep 2007 22:53:34 +0530 Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Mon, Sep 10, 2007 at 07:05:00PM +0200, Jan Engelhardt wrote:
On Sep 10 2007 22:40, Srivatsa Vaddagiri wrote:
+#ifdef CONFIG_FAIR_GROUP_SCHED
+SUBSYS(cpuctlr)
+#endif
cpuctl, cpuctrl, cpu_controller?
On Mon, Sep 10, 2007 at 10:53:34PM +0530, Srivatsa Vaddagiri wrote:
cpuctl, cpuctrl, cpu_controller?
*shrug* .. I used cpuctlr to mean CPU Controller. Any other short names
would do. From your list, cpuctl or cpuctrl both qualifies IMO!
Unless folks have strong objection to it, I prefer
On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
objection ;) cpuctlr isn't memorable. Kernel code is write-rarely,
read-often. cpu_controller, please. The extra typing is worth it ;)
Ok! Here's the modified patch (against 2.6.23-rc4-mm1).
Signed-off-by : Srivatsa Vaddagiri
On Sep 10 2007 10:22, Andrew Morton wrote:
Unless folks have strong objection to it, I prefer cptctlr, the way it is.
Kernel code is write-rarely, read-often.
I think you mean __read_mostly. :-)
Jan
--
___
Containers mailing list
[EMAIL
On Sep 10 2007 22:58, Srivatsa Vaddagiri wrote:
On Mon, Sep 10, 2007 at 10:53:34PM +0530, Srivatsa Vaddagiri wrote:
cpuctl, cpuctrl, cpu_controller?
*shrug* .. I used cpuctlr to mean CPU Controller. Any other short names
would do. From your list, cpuctl or cpuctrl both qualifies IMO!
On 9/10/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Unless folks have strong objection to it, I prefer cptctlr, the way it is.
By definition any container (about to be renamed control group)
subsystem is some kind of controller so that bit seems a bit
redundant.
Any reason not to just
On 10/09/2007, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
objection ;) cpuctlr isn't memorable. Kernel code is write-rarely,
read-often. cpu_controller, please. The extra typing is worth it ;)
Ok! Here's the modified patch
On 9/10/07, Dmitry Adamushko [EMAIL PROTECTED] wrote:
On 10/09/2007, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
objection ;) cpuctlr isn't memorable. Kernel code is write-rarely,
read-often. cpu_controller, please. The
On 10/09/2007, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
objection ;) cpuctlr isn't memorable. Kernel code is write-rarely,
read-often. cpu_controller, please. The extra typing is worth it ;)
Ok! Here's the modified patch
24 matches
Mail list logo
