Skip site navigation (1)Skip section navigation (2)
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>