From owner-freebsd-smp Sat Dec 9 8:21:36 2000 From owner-freebsd-smp@FreeBSD.ORG Sat Dec 9 08:21:34 2000 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 1DE2A37B400; Sat, 9 Dec 2000 08:21:33 -0800 (PST) Received: from berserker.bsdi.com (cp@localhost.bsdi.com [127.0.0.1]) by berserker.bsdi.com (8.11.1/8.9.3) with ESMTP id eB9GGtH06408; Sat, 9 Dec 2000 09:16:55 -0700 (MST) (envelope-from cp@berserker.bsdi.com) Message-Id: <200012091616.eB9GGtH06408@berserker.bsdi.com> To: Julian Elischer Cc: Poul-Henning Kamp , Mike Smith , smp@FreeBSD.ORG Subject: Re: Netgraph and SMP In-reply-to: Your message of "Fri, 08 Dec 2000 16:03:30 PST." <3A3176D2.C3587387@elischer.org> From: Chuck Paterson Date: Sat, 09 Dec 2000 09:16:55 -0700 Sender: cp@berserker.bsdi.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Once again I would urge people to just make it work now and worry about making it fast later. In this case for now it really seems like we should just wrap it in a macro and use the lock manager, which is know to work. We can go back and fix performance when we have a stable platform and know we are just fixing the bugs we introduce with the speed optimizations. I would even more strongly urge people to not make architectural changes now. There are definately less expensive locks that can be fashioned for specific use profiles, such as almost always reader use. In my opinion we should 1) Get the system converted and stable 2) Make higher performance lock primitives for specific use profiles. 3) Look at making architectural changes to the pre-existing system. Chuck Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message