From owner-freebsd-questions Fri Oct 3 23:57:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA02104 for questions-outgoing; Fri, 3 Oct 1997 23:57:28 -0700 (PDT) Received: from primer.i-connect.net (primer.i-Connect.Net [206.190.143.13]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA02089 for ; Fri, 3 Oct 1997 23:57:26 -0700 (PDT) Received: (qmail 831 invoked by uid 1008); 4 Oct 1997 06:57:51 -0000 Mailing-List: contact freebsd-dlm-help@primer.i-connect.net; run by ezmlm Delivered-To: mailing list freebsd-dlm@primer.i-connect.net Received: (qmail 825 invoked from network); 4 Oct 1997 06:57:50 -0000 Received: from sendero-ppp.i-connect.net (206.190.143.100) by primer.i-connect.net with SMTP; 4 Oct 1997 06:57:50 -0000 Received: (qmail 1938 invoked by uid 1000); 4 Oct 1997 06:57:44 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha-092597 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Fri, 03 Oct 1997 23:57:44 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-dlm@primer.i-connect.net Subject: DLM 0.0.5 Local Performance Sender: owner-freebsd-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Y'all, DLM 0.0.5 kernel driver for FreeBSD will be put out tonight or tomorrow. I cleaned up few things and threw out the timong and debug (#ifdefed out). Here are some exciting timing information. These were all done on a fully populated (4096 8bit locks) channel. The test is very simple; Apply the same lock 1million times. Since we do not cache anything, these should be realistic. Times were derived from getrusage and the internal metrics collection in the driver. All times are in microseconds. Test 1. Search for a lock by lock ID. No Conflict. Lock: User = 1.289, System = 11.376, Total = 12.665 Unlock: User = -1 (?) System = 0.129, Total = 0.129 Test 2. Search for a lock by key value in the index. No conflict. Lock: User = 1.110, System = 11.637, Total = 12.747 Unlock: User = -1 (?) System = 0.129, Total = 0.129 Aftere these were done, the dump from the driver's metrics indicated: Create: Fastest = 21, Slowest = 531 Lock: Fastest = 3, Slowest = 534 Unlock: Fastest = 3, Slowest = 45 Analysis of the numbers reveals that they are correct; They tie together exactly. This removes several questions, for the time being; The binary tree logic is fast enough. It actually is a bit faster than dereferencing the array index used by resolving the lock ID. How about removing the lock ID logic, then? It is inherently dangerous. This will save us several nested if statements. We had a big performance problem. It disapears when we turn of the kernel option DLM_DEBUG. How about #ifdef`ing the metrics? We may shave few microseconds as the code is quite invasive. DLMCTL News: I added the -t option. It allows you to run the loop test used for this test. See the sources. --- Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313