Re: [RFC/RFT PATCH] sched: automated per tty task groups

From: Mathieu Desnoyers
Date: Thu Oct 21 2010 - 12:22:26 EST


* Markus Trippelsdorf (markus@xxxxxxxxxxxxxxx) wrote:
> On Thu, Oct 21, 2010 at 10:52:45AM +0200, Mike Galbraith wrote:
> > On Thu, 2010-10-21 at 10:48 +0200, Markus Trippelsdorf wrote:
> > > On Thu, Oct 21, 2010 at 10:11:55AM +0200, Mike Galbraith wrote:
> > > > On Wed, 2010-10-20 at 04:56 +0200, Ingo Molnar wrote:
> > > >
> > > > > Mind doing more of the tty->desktop renames/generalizations as Linus suggested, and
> > > > > resend the patch?
> > > >
> > > > Here she comes. Better/Worse?
> > > >
> > > > Changes:
> > > > - tty->autogroup.
> > > > - only autogroup fair class tasks.
> > > > - removed dainbramaged sleeper vruntime twiddling.
> > > > - removed paranoid locking.
> > > > - removed noop detatch code.
> > > >
> > > > > I'd also suggest to move it out of EXPERIMENTAL - we dont really do that for core
> > > > > kernel features as most distros enable CONFIG_EXPERIMENTAL so it's a rather
> > > > > meaningless distinction. Since the feature is default-n, people will get the old
> > > > > scheduler by default but can also choose this desktop-centric scheduling mode.
> > > > >
> > > > > I'd even argue to make it default-y, because this patch clearly cures a form of
> > > > > kbuild cancer.
> > > >
> > > > You top dogs can make the default call.. it it's accepted that is ;-)
> > > >
> > > > Marcus: care to try the below? Works fine for me (but so did first
> > > > cut). It depends on the attached patch, and applied to virgin shiny new
> > > > 2.6.36.
> > >
> > > Works fine interactively, but I still get the same kernel BUG on reboot
> > > time as before. Would a photo of the trace help you?
> >
> > Odd. Yeah, please send me the photo and your .config.
>
> OK here you go. Both are attached.

In the backtrace, the scheduler is called from:

do_group_exit()
__dequeue_signal()
do_exit()

given that task_group() is called from many spots in the scheduler, I wonder if
some checks making sure that tg != NULL in task_group() would be appropriate ?
Also checking that p->signal is non-NULL in autogroup_attach_tty() might help.

Thanks,

Mathieu


--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/