lkml.org 
[lkml]   [2005]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 5/5] sched: consolidate sbe sbf

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

\
 
 \ /
  Last update: 2005-04-07 09:27    [W:0.037 / U:35.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site