From owner-freebsd-smp  Mon Apr 28 12:05:59 1997
Return-Path: <owner-smp>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id MAA02004
          for smp-outgoing; Mon, 28 Apr 1997 12:05:59 -0700 (PDT)
Received: from who.cdrom.com (who.cdrom.com [204.216.27.3])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA01999
          for <FreeBSD-SMP@freebsd.org>; Mon, 28 Apr 1997 12:05:56 -0700 (PDT)
Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12])
          by who.cdrom.com (8.8.5/8.6.11) with ESMTP id MAA02001
          for <FreeBSD-SMP@freebsd.org>; Mon, 28 Apr 1997 12:05:52 -0700 (PDT)
Received: from pc5829.hil.siemens.at (root@firix [10.1.143.100])
	by zwei.siemens.at  with ESMTP id VAA12178;
	Mon, 28 Apr 1997 21:03:09 +0200 (MET DST)
Received: from localhost (mingo@localhost) by pc5829.hil.siemens.at (8.6.12/8.6.9) with SMTP id VAA16263; Mon, 28 Apr 1997 21:08:15 +0200
Date: Mon, 28 Apr 1997 21:08:15 +0200 (MET DST)
From: Ingo Molnar <mingo@pc5829.hil.siemens.at>
To: Terry Lambert <terry@lambert.org>
cc: Chris Csanady <ccsanady@nyx.pr.mcs.net>, black@zen.cypher.net,
        chuckr@mat.net, FreeBSD-SMP@freebsd.org
Subject: Re: SMP
In-Reply-To: <199704281741.KAA02151@phaeton.artisoft.com>
Message-ID: <Pine.LNX.3.95.970428210208.16129A-100000@pc5829.hil.siemens.at>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


On Mon, 28 Apr 1997, Terry Lambert wrote:

> > Actually, linux has moved to a slightly finer grain system.  Now they
> > have seperate locks for the run queues, scheduler, and some other
> > things..

> This is not much of a symmetry win; it also isn't a scalable win if
> they don't place the locks in a hierarchical relationship.  Without
> that change, they are subject to deadly embrace deadlocks if they get
> any more complex in their locking structure.

what kind of deadlocks do you picture. We only have spinlocks in Linux and
we disallow scheduling with held spinlocks. [thus you can think of those
locks like atomic operations]. There isnt much to be done wrong there. 
Anything that gets out of the big kernel lock is done via totally parallel
code and spinlocks after that. 

[ and resource locking is just done the same way like on uniprocessor
  Linux, on a per-object basis ]

-- mingo