From owner-freebsd-smp  Fri May  2 07:15:46 1997
Return-Path: <owner-smp>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id HAA02256
          for smp-outgoing; Fri, 2 May 1997 07:15:46 -0700 (PDT)
Received: from aviion.ts.kiev.ua (aviion.ts.kiev.ua [193.124.229.12])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA02251
          for <FreeBSD-SMP@FreeBSD.org>; Fri, 2 May 1997 07:15:42 -0700 (PDT)
Received: from nbki.ipri.kiev.ua by aviion.ts.kiev.ua with ESMTP id PAA24900;
  (8.6.11/zah/2.1) Fri, 2 May 1997 15:01:53 GMT
Received: from cki.ipri.kiev.ua by nbki.ipri.kiev.ua with ESMTP id QAA10011;
  (8.6.9/zah/1.1) Fri, 2 May 1997 16:00:05 +0100
Received: from 194.44.146.14 (mac.ipri.kiev.ua [194.44.146.14]) by cki.ipri.kiev.ua (8.7.6/8.7.3) with SMTP id QAA00331; Fri, 2 May 1997 16:11:01 +0300 (EET DST)
Message-ID: <3369DA00.5A6B@cki.ipri.kiev.ua>
Date: Fri, 02 May 1997 15:11:27 +0300
From: Ruslan Shevchenko <rssh@cki.ipri.kiev.ua>
Reply-To: rssh@cki.ipri.kiev.ua
Organization: IPRI
X-Mailer: Mozilla 3.01Gold (Macintosh; I; 68K)
MIME-Version: 1.0
To: Chris Csanady <ccsanady@nyx.pr.mcs.net>
CC: Ben Black <black@zen.cypher.net>, Chuck Robey <chuckr@mat.net>,
        FreeBSD-SMP@FreeBSD.org
Subject: Re: SMP
References: <199704280416.XAA12986@nyx.pr.mcs.net>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-smp@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

Chris Csanady wrote:
> 
> >i sit corrected.  i expect they will eventually migrate to a fully
> >threaded kernel.
> 
> As will we I hope.  I was hoping to work on pushing the locks down
> into the syscalls earlier, but I ran into some trouble.  I really
> knew very little about assembly, and our locks really are not up
> to it yet. :(
> 
> Besides, the general concencus was that we didn't want to deal with
> it now..
> 
> --Chris Csanady
> 
> >On Sun, 27 Apr 1997, Chris Csanady wrote:
> >
> >>
> >> >freebsd-smp is not the best example of how to do SMP.  it uses the
> >> >simplest method: one giant kernel lock.  i don't know that it is
> >> >particularly representative of advanced SMP operating systems (though
> >> >linux also uses a giant kernel lock).
> >>
> >> Actually, linux has moved to a slightly finer grain system.  Now they
> >> have seperate locks for the run queues, scheduler, and some other
> >> things..
> >>
> >> --Chris Csanady
> >>

In principle, the *correct* way: split kernel on subsystems,
write IDL interfases  (of course, on paper, not in srsc)
, and analize.