lkml.org 
[lkml]   [2010]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC/RFT PATCH v3] sched: automated per tty task groups
    From
    Date
    On Tue, 2010-11-16 at 14:04 +0100, Oleg Nesterov wrote:
    > On 11/15, Mike Galbraith wrote:
    > >
    > > On Mon, 2010-11-15 at 13:57 +0100, Oleg Nesterov wrote:
    > >
    > > > And the exiting task can do a lot before it disappears, probably
    > > > we shouldn't ignore ->autogroup.
    >
    > I don't really understand what makes the exiting task different,
    > but OK.
    >
    > However, I must admit I dislike this check. Because, looking at this
    > code, it is not clear why do we check PF_EXITING. It looks as if it
    > is needed for correctness.

    Is _not_ needed I presume.

    I'll remove it, I'm not overly attached (a t t a..;) to it.

    > OK, this is minor. I think the patch is correct, just one nit below.
    >
    > > > It can't protect the change of signal->autogroup, multiple callers
    > > > can use different rq's.
    > >
    > > Guaranteed live ->autogroup should be good enough for heuristic use, and
    > > had better be so. Having to take ->siglock in the fast path would kill
    > > using ->signal.
    >
    > Yes, sure, rq->lock should ensure signal->autogroup can't go away.
    > (even if it can be changed under us). And it does, we are moving all
    > threads before kref_put().

    (yeah)

    > > +static void
    > > +autogroup_move_group(struct task_struct *p, struct autogroup *ag)
    > > +{
    > > + struct autogroup *prev;
    > > + struct task_struct *t;
    > > +
    > > + prev = p->signal->autogroup;
    > > + if (prev == ag)
    > > + return;
    > > +
    > > + p->signal->autogroup = autogroup_kref_get(ag);
    > > + sched_move_task(p);
    > > +
    > > + rcu_read_lock();
    > > + list_for_each_entry_rcu(t, &p->thread_group, thread_group) {
    > > + sched_move_task(t);
    > > + }
    > > + rcu_read_unlock();
    > > +
    > > + autogroup_kref_put(prev);
    > > +}
    >
    > Well, this looks a bit strange (but correct).

    My mouse copied it.

    > We are changing ->autogroup assuming the caller holds ->siglock.
    > But if we hold ->siglock we do not need rcu_read_lock() to iterate
    > over the thread_group, we can just do
    >
    > p->signal->autogroup = autogroup_kref_get(ag);
    >
    > t = p;
    > do {
    > sched_move_task(t);
    > } while_each_thread(p, t);
    >
    > Again, this is minor, I won't insist.

    I'll do it that way. I was pondering adding the option to move one or
    all as cgroups does, but don't think that will ever be needed.

    Thanks,

    -Mike



    \
     
     \ /
      Last update: 2010-11-16 15:21    [W:0.025 / U:1.548 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site