John Baldwin wrote:
I wouldn't sell yourself so short actually. :) You're probably more competent
than you think. I'm not really an expert on SMP or schedulers either (I've
not had any formal training, and if you were to review some of my earlier SMP
stuff it shows), but ended up working on it because it needed to be done.
Most of what I've learned is by just working on stuff. Anyways, maybe this
issue will bubble up to someone's todo list at BSDCan to settle how to handle
CPU's arriving and departing. One big thing that worries me is how to handle
pinned and bound threads when a CPU goes away. Also, it may be more useful
to think of CPUs not as just present/not present, but more in terms of:
- not present
- present but offline
- present and online
And most code would really only care about offline/online events. We could
maybe allow pinned and bound threads to still run on an offline CPU (and the
idlethread for that CPU of course) but require that there be no pinned bound
threads to completely detach a CPU (in the case of systems with removable
CPUs). It would be useful to at least handle taking CPUs offline and then
back online though.
I think this is a good design, assuming that all code that creates a
thread and pins it are forced to register to receive events. That way
you don't end up with a thread pinned and blocking the CPU going away.
This capability will also be useful for suspend/resume on SMP since we
need to stop CPUs and then restart them after resume.
--
Nate
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
