Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934468Ab0KPNLN (ORCPT ); Tue, 16 Nov 2010 08:11:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18925 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756379Ab0KPNLM (ORCPT ); Tue, 16 Nov 2010 08:11:12 -0500 Date: Tue, 16 Nov 2010 14:04:13 +0100 From: Oleg Nesterov To: Mike Galbraith Cc: Peter Zijlstra , Linus Torvalds , Markus Trippelsdorf , Mathieu Desnoyers , Ingo Molnar , LKML Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups Message-ID: <20101116130413.GA29368@redhat.com> References: <1289778189.5154.10.camel@maggy.simson.net> <1289783580.495.58.camel@maggy.simson.net> <1289811438.2109.474.camel@laptop> <1289820766.16406.45.camel@maggy.simson.net> <1289821590.16406.47.camel@maggy.simson.net> <20101115125716.GA22422@redhat.com> <1289856350.14719.135.camel@maggy.simson.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1289856350.14719.135.camel@maggy.simson.net> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2043 Lines: 71 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. 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(). > +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). 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. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/