Date: Thu, 7 Apr 2005 09:15:53 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel <linux-kernel@vger.kernel.org>,
       "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Subject: Re: [patch 5/5] sched: consolidate sbe sbf
Message-ID: <20050407071553.GB26607@elte.hu>
References: <425322E0.9070307@yahoo.com.au> <42532317.5000901@yahoo.com.au> <42532346.5050308@yahoo.com.au> <425323A1.5030603@yahoo.com.au> <42532427.3030100@yahoo.com.au> <20050406062723.GC5973@elte.hu> <4253993C.4020505@yahoo.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4253993C.4020505@yahoo.com.au>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1275
Lines: 32


* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> We could just do a set_cpus_allowed, or take the lock, 
> set_cpus_allowed, and take the new lock, but that's probably a bit 
> heavy if we can avoid it. In the interests of speed in this fast path, 
> do you think we can do this in sched_fork, before the task has even 
> been put on the tasklist?

yeah, that shouldnt be a problem. Technically we set cpus_allowed up 
under the tasklist lock just to be non-preemptible and to copy the 
parent's _current_ affinity to the child. But sched_fork() is called 
just before and if the parent got its affinity changed between the two 
calls, so what? I'd move all of this code into sched_fork().

> That would avoid all locking problems. Passing clone_flags into 
> sched_fork would not be a problem if we want to distinguish fork() and 
> clone(CLONE_VM).

sure, that was the plan all along with sched_fork() anyway. (i think the 
initial versions had the flag)

> Yes? I'll cut a new patch to do just that.

sure, fine by me.

	Ingo
-
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/