Date: Thu, 07 Aug 1997 17:08:17 -0600 From: Steve Passe <smp@csn.net> To: smp@freebsd.org Cc: current@freebsd.org Subject: HEADS UP: programming the SMP kernel Message-ID: <199708072308.RAA25847@Ilsa.StevesCafe.com>
next in thread | raw e-mail | index | archive | help
Hi, This posting describes important issues for the ongoing coding effort of the SMP kernel. If you expect to be participating in this effort, or maintain kernel code that may be touched by it (every major sub-system: VFS, VM, net, etc.) then you should at least monitor this thread. Please trim 'current@freebsd.org' from replys, I want to keep the traffic limited to the smp list, both to eliminate redundancy and to spare those in current with no interest in it. ----------------------------------------------------------------------------- We need to agree on the set of primatives available for coding SMP specific kernel code. Along with this we need a concise document describing the dos and donts of SMP conforming code. --- The lock primitives: It is expected that the lite2 locks will be the primary locking mechanism for SMP. A description can be found in: http://www.freebsd.org/~fsmp/SMP/Locking.html The simplelock functions are implimented and working, but the higher level lock manager cannot yet be enabled. It is expected that this will be fixed by next week. --- Deadlock management: I am leaning towards deadlock prevention, using the "resource ordering method", as oppossed to deadlock detection or avoidance. In the "resource ordering method" all resources are uniquely ordered in ascending order. A process can only compete for resources higher in precedence than the highest it currently holds. This prevents 'circular wait' or 'deadly embrace' deadlocks. Its good points are simplicity and reliability. Its bad points are the enforced discipline in writting code, ie a fair amount of work will be necessary to produce the properly ordered list. --- The existing spl code: We will most likely have to introduce some form of queueing mutex to order the access of CPUs inside the kernel. This is more or less the equivilant of spl/cpl in the UP kernel. spl is ineffective for SMP and redundant in purpose to mutexs for the SMP case. Stated another way, SMP mutexs make spl obsolete. So the issue before the house is how to accommidate both in one source tree. The 'proper' method is probably to eliminate spl entirely for both UP and SMP, replacing it with a system of mutex calls. There would probably be minor differences in the coding for each(UP & SMP), but that detail would be localized to the implimentation file for mutex itself. I know this one is a biggie, and will probaly generate a lot of comment. But its the gate we stand at, and its time to enter... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708072308.RAA25847>