Date: Wed, 3 Jul 1996 14:33:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rashid@rk.ios.com (Rashid Karimov) Cc: questions@freebsd.org Subject: Re: SMP supports. Message-ID: <199607032133.OAA11337@phaeton.artisoft.com> In-Reply-To: <199607011616.MAA09265@rk.ios.com> from "Rashid Karimov" at Jul 1, 96 12:16:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
I haven't seen an answer for this, so I'll try. Note that I am a FreeBSD and SMP advocate, not a core team member. > when will guys at freebsd.org plug extra PPro(s) > into ftp.freebsd.org's Alder ? :))) No idea. I'm not involved. 8-). > where can we find most up-date info on SMP in > FreeBSD ? On the SMP mailing list. Youcan join by: echo "subscribe freebsd-smp" | mail majordomo@freebsd.org > How naturally does it go so far ? It works, with some scheduler issues outstanding, for low grain (single kernel entrancy) SMP. The scheduler issues are from the changeover from the Jack Vogel model to a more traditional (less advanced, less scalable, more cache-effective) scheduling model. > Any guidelines for current kernel developers ? > Locking ( semaphores/mutex'es) primitives to use ? None currently. There is some disagreement about how parallelization should be achieved above the low grain level. There are also some issues which need to be resolved in the Lite2 integration to enable additional patches to be applied without interfering with the integration effort. There are generally two camps: the scheduler camp, and the pushdown camp; I am a member of the pushdown camp, since I have worked on SMP kernels for over 4 years as a former Novell/USL employee, and I have seen that approach work in practice in SVR4.0.2 ES/MP (Unisys) and Solaris, SVR4.2 (UNixWare 2.x) and Sequent implementations. Jack Vogel (who currently works on the Solaris SMP kernel for SunSoft) is in the same camp, though he also has some radical (and generally unpopular, because of the attendant risk) ideas on scheduling, which trade off L1 and L2 cache coherency for *massive* scalability. With Intel processors, most of us agree that the APIC limitation of 5 bits makes 128 processors (Motorolla) the probable "high end", and we aren't aiming for the 1024-65536 (supescalar) processor hardware Jack was aiming at. I'm personally aiming at 64 processor PPC620 machines from a German Motorolla OEM, and at the 1GHz clock PPC chips that Motorolla has demonstrated operating in their Phoenix facility. > It looks to me that current kernel development > goes being completely SMP-unaware, even though full > SMP support is clearly future of FreeBSD project and > as I understand we already have working systems. Yes, that's true. From kernel reeentrancy, to simplified state management (single-entry/single-exit, etc.), there is not any enforcement of SMP-safe or multithreading capable coding styles for new code. I expect this will change as of 2.2, which is planned to include the SMP code into the main line code tree; John Dyson (among others) is already in posession of another contributors full-on kernel threading implementation. I'd like to add hooks for non-quantum-restrictive user-to-kernel thread mappings at some point in the future to ensure application scalability over many processors. This is expected to reduce context switching overhead for multithreading by a factor of three or more over the model used by Solaris/SVR4.2-ESMP. There are also VM pero processor pool locality changes that the Solaris/SVR4 VM SLAB allocation implementation can not take advantage of (this is the source of the anecdotal "8 processor limit" for Intel machines, and is based on increasing bus contention for the interprocessor synchronization to support the unified SLAB model). You shouldn't worry that we are still integrating non-reentrant, non-kernel-preemption-safe code into the tree at this point. If we are still doing that in 6-8 months, then you should start worrying. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607032133.OAA11337>