From owner-freebsd-alpha Wed Sep 4 21:50:46 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C71D537B400; Wed, 4 Sep 2002 21:50:43 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6441143E6E; Wed, 4 Sep 2002 21:50:43 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0312.cvx40-bradley.dialup.earthlink.net ([216.244.43.57] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17mob4-00056M-00; Wed, 04 Sep 2002 21:50:27 -0700 Message-ID: <3D76E256.6A200E16@mindspring.com> Date: Wed, 04 Sep 2002 21:49:26 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Andrew Gallatin , John Baldwin , freebsd-alpha@freebsd.org Subject: Re: alpha performance on -current References: <20020905013034.1D4B42A88D@canning.wemm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Peter Wemm wrote: > Andrew Gallatin wrote: > > [non-null null syscall tests] > > We really need a null system call to test for these. How about > __sysnull(2)? What lmbench is testing is syscall overhead *plus* several > iterations of mutex gain/releases. Possibly with a couple of sysctl knobs > to enable turning on of "typical" locking operations. eg: > kern.sysnull.giant = gain/release giant, kern.sysnull.proc = gain/release > proc lock etc. Then we can easily test the *actual* syscall overhead. Isn't this a reasonable thing for it to test? Or are there system calls that don't have the several iterations of mutex gain/release? IMO, the test should be "all code that is common to all system calls". If this yields bad numbers for now, that's fine, as long as it gets optimized at some point in the future, there should be no problem with the numbers indicating what needs to be optimized. At least that way, the benchmark would have *some* real meaning. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message