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_cp
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
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 th
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 appr
* 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 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(
Hi Srivatsa,
please find a few more minor comments below.
> [ ... ]
> +
> +/* destroy runqueue etc associated with a task group */
> +static void sched_destroy_group(struct container_subsys *ss,
> + struct container *cont)
> +{
> + struct task_grp *tg =
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
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 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 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
contai
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 scheduler with the
task-container framework in -mm tree, so that the schedu
On Sep 11 2007 08:22, Randy Dunlap wrote:
>> "cfs" control group subsystem.
>
>That looks odd, like it's a filesystem.
>What does cfs really mean?
http://en.wikipedia.org/wiki/CFS
(scnr)
It misses the C...something Filesystem tho.
Jan
--
__
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 ;) "c
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
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
On Mon, Sep 10, 2007 at 11:38:10AM -0700, Paul Menage wrote:
> 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 call it "cpu" or "cpu_sched"
Done (in the latest patch I sent a w
On Tue, Sep 11, 2007 at 12:28:51AM +0200, Dmitry Adamushko wrote:
> > + rq = task_rq_lock(tsk, &flags);
> > +
>
> I guess, update_rq_clock(rq) should be placed here.
>
> humm... do you really need deactivate/activate_task() here? 'rq' and
> p->se.load.weight stay unchanged so enqueue/dequeu
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 mod
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 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 mod
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
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 qualifie
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
[E
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 Vaddag
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,
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, c
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
woul
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
__
29 matches
Mail list logo
