[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1292910611.6614.18.camel@marge.simson.net>
Date: Tue, 21 Dec 2010 06:50:11 +0100
From: Mike Galbraith <efault@....de>
To: Bharata B Rao <bharata.rao@...il.com>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>, mingo@...hat.com,
hpa@...or.com, linux-kernel@...r.kernel.org,
mathieu.desnoyers@...icios.com, torvalds@...ux-foundation.org,
pjt@...gle.com, markus@...ppelsdorf.de, tglx@...utronix.de,
oleg@...hat.com, mingo@...e.hu, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:sched/core] sched: Add 'autogroup' scheduling feature:
automated per session task groups
On Tue, 2010-12-21 at 10:34 +0530, Bharata B Rao wrote:
> On Mon, Dec 20, 2010 at 10:09 PM, Mike Galbraith <efault@....de> wrote:
> > On Mon, 2010-12-20 at 21:16 +0530, Bharata B Rao wrote:
> >> On Mon, Dec 20, 2010 at 6:49 PM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> >> > On Mon, 2010-12-20 at 18:38 +0530, Bharata B Rao wrote:
> >> >> The autogroup patchset removes the display of cgroup name from
> >> >> sched_debug output.
> >> >
> >> > Hrmph.. that wasn't supposed to happen, care to send a patch to fix that
> >> > up?
> >>
> >> There are two aspects here:
> >>
> >> - Printing cgroup name for per-CPU cfs_rqs shouldn't be affected by
> >> autogroup and the old code should work here.
> >> - Printing cgroup name for tasks depends on task_group(), which has
> >> been changed by autogroup patch. I haven't really looked deep into
> >> autogroup patch, but from whatever I can gather, Mike had a reason
> >> to remove this bit from sched_debug. The task groups created for
> >> autogroups don't have cgroups associated with them and hence no
> >> dentries and hence no pathnames.
> >
> > Mike didn't remove it, but _was_ supposed to get around to it.
> >
> >> I guess we could do fix this as shown in the attached patch.
> >
> >
> > +#ifdef CONFIG_CGROUP_SCHED
> > + {
> > + char path[64];
> > +
> >
> > ...
> >
> > +#if defined(CONFIG_CGROUP_SCHED) && defined(CONFIG_FAIR_GROUP_SCHED)
> > + char path[128];
> >
> >
> > One reason it was removed was path[64/128].
>
> Other callers of cgroup_path use PATH_MAX=4096 here. I believe the
> original reason for these short path sizes was to be light on stack
> and as well as to avoid allocation. Can we have some reasonable length
> (256 or 512 ?) and live with truncation (if that ever happens) ?
I don't see why not, unlikely situation in non-critical path.
> Also, while displaying group name with tasks, does it make sense to
> display autogroup-<id> (the one shown in /proc/<pid>/autogroup) ?
I did to me obviously :) I'm fine with it not showing up, though if it
survives and evolves, maybe it'll want visibility. ATM, you know what's
in what group via ps -o foo,session.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists