Date: Tue, 09 Oct 2001 20:08:13 -0700 From: "Charles Burns" <burnscharlesn@hotmail.com> To: questions@freebsd.org Subject: Re: dual processor support Message-ID: <F164iWwSoRKbpG1Kiae00001a17@hotmail.com>
next in thread | raw e-mail | index | archive | help
>so then what is SMP thats going to be new and great in version 5?? i >thought that was dual processor? > >nathan Supporting SMP is more complex than just "supporting" or "Not supporting". How efficiently are the different processors used? How many processors can be used effectively? Does the operating system assign different threads of the same program well? Simple SMP support alows for, example, two processor intensive programs to run (SETA@Home and Distributed.net client, for example), each using a CPU. That's a simplified example, though. Here's a real-world example: Running Oracle, the new Sun Starcat server with 72 processors (it can have up to 106, but anyway) is about 80% efficient when running a certain series of select statements. That means that it is running about 80% as fast as (the speed using just 1 processor * the # of processors). Linux on an IBM server with 16 processors running IBM's DB7 with similar statements was about 47% efficient. You never get an exact doubling of performance when doubling the # of processors--only in a perfect world (or when running highly specific programs that can benefit from the added L2 cache) While FreeBSD is probably fine with, say, 2 or even 4 processors (I don't knwo, my system has only 1)--You would probably get almost no benefit increasing that to, say, 32 procesors. By improving the SMB support, more CPUs can be used well and few CPUs can be used more efficiently. Here's a portion of an interview with Matt Dillon, the designer of FreeBSD's excellent virtual memory subsystem, about SMP: --------------------------=--------------------------- 6. Please explain to us what SMPng (next-generation symmetric multi-processing) and KSE (kernel scheduler entities) are, which are features to be found on the BSD-5-Current. Matt Dillon: SMPng is FreeBSD's fine-grained mutex, interrupt threading, and Giant-removal implementation. Potentially kernel pre-emption is also part of the equation but the jury is still out on that. The purpose is to be able to have several mainline processes and/or interrupts operating in kernel mode simultaniously. This is the primary scaleability issue in any SMP system. The work being done here is roughly compareable to the SMP work being done in Linux. Linux is about a year ahead of us but both Linux and the BSDs have a great deal of work to do to catch up with Solaris. KSE is a totally new (but old idea) way of implementing userland threads. The idea here is two fold: (1) to remove any requirement that userland code understand which system calls might block and which system calls might not block. (2) to do all primary thread scheduling and switching in userland, where any given cpu can switch between threads with approximately the same overhead as a userland subroutine call. With KSEs if a userland process makes a system call which blocks, the kernel will detach the kernel context (which is now blocked) and return directly to the user mode scheduler using an 'upcall'. The userland scheduler can then immediately switch to another thread. Another system call will be given a new, fresh, KSE to play with. The blocked kernel context runs completely asynchronously from the userland process until it finishes and can potentially run concurrently with other detached KSEs for the same process. When a KSE completes the kernel notifies the userland scheduler allowing the userland scheduler to reschedule the 'blocked' thread which is now 'returning' from the system call that originally blocked. The essential difference between KSEs and both select/kqueue-based threads and rfork based threads is that with KSEs you get all the parallelism of the SMP box and all the power of a userland-only context switch between threads (read: *very* fast switch times) without *any* of the kernel overhead. A program can literally be running thousands of threads with no significant kernel overhead. Only blocked system calls eat kernel resources. In addition to this, we can manage kernel resources in the face of thousands of threads by limiting the 'pool' of KSEs we assign to any given process or user or whatever. So if 500 of those 1000 threads block in a syscall we just get a little less cpu-efficient and don't blow out kernel memory. Currently FreeBSD can use both select/kqueue and rfork (linux-style) threading. KSEs bring us to the next level. --------------------------=--------------------------- (Full article: http://www.osnews.com/story.php?news_id=153) Charles Burns > > > > On Tue, 9 Oct 2001 19:18:32 -0400 > > Nathan Mace <nmace85@yahoo.com> wrote: > > > > > the only freebsd verion that currently supports dual processors on > > i386 > > > chips is -Current or 5.0..right? > > > > No, that is incorrect. The 4-branch of FreeBSD supports more than one > > processor. I'm enjoying it now on a dual Pentium Pro200 system. ;-) _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F164iWwSoRKbpG1Kiae00001a17>