Messages in this thread | | | Subject | Re: [RFC/RFT PATCH] sched: automated per tty task groups | From | Mike Galbraith <> | Date | Thu, 21 Oct 2010 13:27:20 +0200 |
| |
On Thu, 2010-10-21 at 06:51 -0400, Mathieu Desnoyers wrote: > * Mike Galbraith (efault@gmx.de) wrote: > [...] > > +static void > > +autogroup_attach_tty(struct task_struct *p, struct task_group **tg) > > +{ > > + struct tty_struct *tty = p->signal->tty; > > + > > + if (!tty) > > + return; > > + > > + *tg = p->signal->tty->tg; > > +} > > + > > +static inline void > > +autogroup_check_attach(struct task_struct *p, struct task_group **tg) > > +{ > > + if (!sysctl_sched_autogroup_enabled || *tg != &root_task_group || > > + p->sched_class != &fair_sched_class) > > + return; > > + > > + rcu_read_lock(); > > + > > + autogroup_attach_tty(p, tg); > > + > > + rcu_read_unlock(); > > +} > > + > > Hi Mike, > > This per-tty task grouping approach looks very promising. I'll give it a spin > when I find the time. Meanwhile, a little question about locking here: how is > the read lock supposed to protect from p->signal (and p->signal->tty) > modifications ? What's the locking scheme here ? So maybe just simple > rcu_dereference are missing, or maybe the tsk->sighand->siglock might be > required. In all cases, I feel something is missing there.
My assumption is that no additional locking is needed. The tty is refcounted, dropped in release_task()->__exit_signal(), at which point the task is unhashed, is history. The tty can't go away until the last task referencing it goes away.
-Mike
| |