Subject: Re: Moving scheduler semantics from cpu_switch() to kern_synch.c
To: matthew green <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 09/21/2006 10:09:22
matthew green wrote:
> > it just seems suboptimal to have to set a flag in every cpu_info when
> > there is a (random) process to run.
> You would not set it in every cpu_info... the idea is that processes
> would be "bound" to CPUs to eliminate the cache thrash that we
> currently have because processes can migrate between CPUs randomly.
> We're talking about per-CPU run queues, here.
> so every process is bound to a cpu? i guess i don't understand how
> this works to avoid cpus idling while lwps are waiting for "their"
> cpu to become free... who runs a new process first? right now it
> is who ever tries to first.
Can this be managed with scheduling priorities? I.e. you take a -5 (or
some other random constant) hit against your scheduling priority when
your process is being considered for scheduling on a CPU other than your
"preferred" one? It won't be perfect, but I imagine it would seriously
help the thrash. And you still have the idle thread at the absolute
bottom level, so IDLE is only ever run on a processor if _no_ thread can
be scheduled on it.
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191