From owner-freebsd-hackers Sun Jul 14 11:38:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA26362 for hackers-outgoing; Sun, 14 Jul 1996 11:38:01 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA26350 for ; Sun, 14 Jul 1996 11:37:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with SMTP id MAA09822; Sun, 14 Jul 1996 12:37:49 -0600 (MDT) Message-Id: <199607141837.MAA09822@rover.village.org> To: Michael Hancock Subject: Re: Some interesting papers on BSD ... Cc: freebsd-hackers@freebsd.org, tech-kern@netbsd.org In-reply-to: Your message of Sun, 14 Jul 1996 17:52:51 +0900 Date: Sun, 14 Jul 1996 12:37:48 -0600 From: Warner Losh Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk : It's the quick and dirty route to getting an SMP version out the door : under budgetary or market timing constraints. : : To do it right, sections of code have to be rewritten to make the code as : parallel as possible. How is that different from taking out fine grain locks? Or does the rewrite make it possible to hold these locks for shorter periods of time and have the synergistic effect of causing less lock contention. If there is a good reference to this, I would love to be enlightened by it. : Caching also works very differently with multiple CPU's. That's true no matter how you do SMP (or even ASMP)... Warner