lkml.org 
[lkml]   [2010]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC/RFT PATCH] sched: automated per tty task groups
From
Date
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



\
 
 \ /
  Last update: 2010-10-21 13:29    [W:0.172 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site