On Mon, 2011-02-07 at 11:28 -0800, Paul Menage wrote:
> On Mon, Feb 7, 2011 at 8:10 AM, Peter Zijlstra <pet...@infradead.org> wrote:
> >
> > Make the ::exit method act like ::attach, it is after all very nearly
> > the same thing.
>
> The major difference between attach and exit is that the former is
> only triggered in response to user cgroup-management action, whereas
> the latter is triggered whenever a task exits, even if cgroups aren't
> set up.
And the major likeness is that they both migrate a task from one cgroup
to another. You cannot simply ignore that.
> > void cgroup_exit(struct task_struct *tsk, int run_callbacks)
> > {
> > - int i;
> > struct css_set *cg;
> > + int i;
> >
> > - if (run_callbacks && need_forkexit_callback) {
> > - /*
> > - * modular subsystems can't use callbacks, so no need to
> > lock
> > - * the subsys array
> > - */
> > - for (i = 0; i < CGROUP_BUILTIN_SUBSYS_COUNT; i++) {
> > - struct cgroup_subsys *ss = subsys[i];
> > - if (ss->exit)
> > - ss->exit(ss, tsk);
> > - }
> > - }
> > + mutex_lock(&cgroup_mutex);
>
> NACK - cgroup_mutex is way too heavy to take in the task exit path.
> We'll need to find some other way to fix this if it's really needed.
> task->alloc_lock is also normally a valid thing to synchronize against
> cgroup moves, but I'd have to look at the exit path to see if it's
> still valid there.
If maybe you're like respond more often than about once every two months
I might actually care what you think.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
