| Message ID | 1274227488.2370.107.camel@w-sridhar.beaverton.ibm.com |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
On Tue, May 18, 2010 at 5:04 PM, Sridhar Samudrala <samudrala.sridhar@gmail.com> wrote: > Add a new kernel API to attach a task to current task's cgroup > in all the active hierarchies. > > Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> Reviewed-by: Paul Menage <menage@google.com> It would be more efficient to just attach directly to current->cgroups rather than potentially creating/destroying one css_set for each hierarchy until we've completely converged on current->cgroups - but that would require a bunch of refactoring of the guts of cgroup_attach_task() to ensure that the right can_attach()/attach() callbacks are made. That doesn't really seem worthwhile right now for the initial use, that I imagine isn't going to be performance-sensitive. Paul -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 20, 2010 at 3:22 PM, Paul Menage <menage@google.com> wrote: > On Tue, May 18, 2010 at 5:04 PM, Sridhar Samudrala > <samudrala.sridhar@gmail.com> wrote: >> Add a new kernel API to attach a task to current task's cgroup >> in all the active hierarchies. >> >> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> > > Reviewed-by: Paul Menage <menage@google.com> > One other thought on this - this would be the first piece of code that's attaching a task to a cgroup without holding the cgroup directory inode i_mutex. I believe that this is probably OK. Paul -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 5/20/2010 3:22 PM, Paul Menage wrote: > On Tue, May 18, 2010 at 5:04 PM, Sridhar Samudrala > <samudrala.sridhar@gmail.com> wrote: > >> Add a new kernel API to attach a task to current task's cgroup >> in all the active hierarchies. >> >> Signed-off-by: Sridhar Samudrala<sri@us.ibm.com> >> > Reviewed-by: Paul Menage<menage@google.com> > > It would be more efficient to just attach directly to current->cgroups > rather than potentially creating/destroying one css_set for each > hierarchy until we've completely converged on current->cgroups - but > that would require a bunch of refactoring of the guts of > cgroup_attach_task() to ensure that the right can_attach()/attach() > callbacks are made. That doesn't really seem worthwhile right now for > the initial use, that I imagine isn't going to be > performance-sensitive. > Yes. In our use-case, this will be called only once per guest interface when the guest comes up. Hope you or someone more familiar with cgroups subsystem can optimize this function later. Thanks Sridhar -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 20, 2010 at 03:22:15PM -0700, Paul Menage wrote: > On Tue, May 18, 2010 at 5:04 PM, Sridhar Samudrala > <samudrala.sridhar@gmail.com> wrote: > > Add a new kernel API to attach a task to current task's cgroup > > in all the active hierarchies. > > > > Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> > > Reviewed-by: Paul Menage <menage@google.com> > > It would be more efficient to just attach directly to current->cgroups > rather than potentially creating/destroying one css_set for each > hierarchy until we've completely converged on current->cgroups - but > that would require a bunch of refactoring of the guts of > cgroup_attach_task() to ensure that the right can_attach()/attach() > callbacks are made. That doesn't really seem worthwhile right now for > the initial use, that I imagine isn't going to be > performance-sensitive. > > Paul Is this patch suitable for 2.6.35? It is needed to fix the case where vhost user might cause a kernel thread to consume more CPU than allowed by the cgroup. Should I just merge it through the vhost tree? Ack for this? Thanks,
On Tue, May 25, 2010 at 9:53 AM, Michael S. Tsirkin <mst@redhat.com> wrote: > On Thu, May 20, 2010 at 03:22:15PM -0700, Paul Menage wrote: >> On Tue, May 18, 2010 at 5:04 PM, Sridhar Samudrala >> <samudrala.sridhar@gmail.com> wrote: >> > Add a new kernel API to attach a task to current task's cgroup >> > in all the active hierarchies. >> > >> > Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> >> >> Reviewed-by: Paul Menage <menage@google.com> >> >> It would be more efficient to just attach directly to current->cgroups >> rather than potentially creating/destroying one css_set for each >> hierarchy until we've completely converged on current->cgroups - but >> that would require a bunch of refactoring of the guts of >> cgroup_attach_task() to ensure that the right can_attach()/attach() >> callbacks are made. That doesn't really seem worthwhile right now for >> the initial use, that I imagine isn't going to be >> performance-sensitive. >> >> Paul > > Is this patch suitable for 2.6.35? Should be OK, yes. Paul -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 25, 2010 at 11:34:12AM -0700, Paul Menage wrote: > On Tue, May 25, 2010 at 9:53 AM, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Thu, May 20, 2010 at 03:22:15PM -0700, Paul Menage wrote: > >> On Tue, May 18, 2010 at 5:04 PM, Sridhar Samudrala > >> <samudrala.sridhar@gmail.com> wrote: > >> > Add a new kernel API to attach a task to current task's cgroup > >> > in all the active hierarchies. > >> > > >> > Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> > >> > >> Reviewed-by: Paul Menage <menage@google.com> > >> > >> It would be more efficient to just attach directly to current->cgroups > >> rather than potentially creating/destroying one css_set for each > >> hierarchy until we've completely converged on current->cgroups - but > >> that would require a bunch of refactoring of the guts of > >> cgroup_attach_task() to ensure that the right can_attach()/attach() > >> callbacks are made. That doesn't really seem worthwhile right now for > >> the initial use, that I imagine isn't going to be > >> performance-sensitive. > >> > >> Paul > > > > Is this patch suitable for 2.6.35? > > Should be OK, yes. > > Paul So I'll add your Acked-by tag then, and merge through the vhost tree together with the patch that uses this.
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h --- a/include/linux/cgroup.h +++ b/include/linux/cgroup.h @@ -570,6 +570,7 @@ struct task_struct *cgroup_iter_next(struct cgroup *cgrp, void cgroup_iter_end(struct cgroup *cgrp, struct cgroup_iter *it); int cgroup_scan_tasks(struct cgroup_scanner *scan); int cgroup_attach_task(struct cgroup *, struct task_struct *); +int cgroup_attach_task_current_cg(struct task_struct *); /* * CSS ID is ID for cgroup_subsys_state structs under subsys. This only works diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 6d870f2..6cfeb06 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -1788,6 +1788,29 @@ out: return retval; } +/** + * cgroup_attach_task_current_cg - attach task 'tsk' to current task's cgroup + * @tsk: the task to be attached + */ +int cgroup_attach_task_current_cg(struct task_struct *tsk) +{ + struct cgroupfs_root *root; + struct cgroup *cur_cg; + int retval = 0; + + cgroup_lock(); + for_each_active_root(root) { + cur_cg = task_cgroup_from_root(current, root); + retval = cgroup_attach_task(cur_cg, tsk); + if (retval) + break; + } + cgroup_unlock(); + + return retval; +} +EXPORT_SYMBOL_GPL(cgroup_attach_task_current_cg); + /* * Attach task with pid 'pid' to cgroup 'cgrp'. Call with cgroup_mutex * held. May take task_lock of task
Add a new kernel API to attach a task to current task's cgroup in all the active hierarchies. Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html