From owner-freebsd-chat Thu Mar 18 7:26:36 1999 Delivered-To: freebsd-chat@freebsd.org Received: from enst.enst.fr (enst.enst.fr [137.194.2.16]) by hub.freebsd.org (Postfix) with ESMTP id 3BA1414BF5 for ; Thu, 18 Mar 1999 07:26:32 -0800 (PST) (envelope-from beyssac@enst.fr) Received: from email.enst.fr (muse-2.enst.fr [137.194.2.33]) by enst.enst.fr (8.9.1a/8.9.1) with ESMTP id QAA26677; Thu, 18 Mar 1999 16:25:58 +0100 (MET) Received: from bofh.enst.fr (bofh.enst.fr [137.194.32.191]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id QAA02585; Thu, 18 Mar 1999 16:25:57 +0100 (MET) Received: by bofh.enst.fr (Postfix, from userid 12426) id 73E53D228; Thu, 18 Mar 1999 16:25:51 +0100 (CET) Message-ID: <19990318162551.A10594@enst.fr> Date: Thu, 18 Mar 1999 16:25:51 +0100 From: Pierre Beyssac To: Nocturne , Sascha Schumann Cc: Greg Lehey , freebsd-chat@FreeBSD.ORG Subject: Re: Real performance comparisons (was: FreeBSD 3.1 SMP outperforms SuSE 6.0 SMP by factor 2.3 !!!) References: <19990316150715.A3316@schell.de> <19990317111720.O429@lemis.com> <19990317173718.A2510@schell.de> <36F10CAE.79A62FF7@uswest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <36F10CAE.79A62FF7@uswest.net>; from Nocturne on Thu, Mar 18, 1999 at 06:24:46AM -0800 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Mar 18, 1999 at 06:24:46AM -0800, Nocturne wrote: > I talked with a friend at considerable length about SMP in Linux vs > FreeBSD and we agreed that newer Linux kernels would be faster than > FreeBSD. This is going on the thinking that Linux uses a subsystem > lock that allows all the CPUs to work on their own parts of the kernel > simultaneously--theoretically eliminating processor idle time--whereas > FreeBSD's spin lock allows only single CPU access at any given moment. As others have said before, this all depends on your application. For pure-CPU jobs with little or no system calls, the granularity of the kernel lock doesn't matter at all. Very thin lock granularity is not the panacea either, as you can end up spending a lot of overhead just for taking/releasing locks. This can really happen if your processes are very system-call intensive. Thus it's necessary to find a balance between lock granularity and overhead that fits most applications. -- Pierre Beyssac pb@enst.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message