Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 03 Oct 1997 23:57:44 -0700 (PDT)
From:      Simon Shapiro <Shimon@i-Connect.Net>
To:        freebsd-dlm@primer.i-connect.net
Subject:   DLM 0.0.5 Local Performance
Message-ID:  <XFMail.971003235744.Shimon@i-Connect.Net>

next in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.971003235744.Shimon>