On Mon, 12 Jul 1999, Matthew Dillon wrote:
> How did that happen?!!! Argg.. I didn't save the email.
>
> Here are better results:
>
> Empty loop:
>
> mode 0 9.21 ns/loop nproc=1 lcks=EMPTY
>
> With and without lock prefix, one and two processes
>
> mode 1 16.48 ns/loop nproc=1 lcks=no
> mode 2 23.65 ns/loop nproc=2 lcks=no
> mode 3 93.02 ns/loop nproc=1 lcks=yes
> mode 4 160.82 ns/loop nproc=2 lcks=yes
>
> With and without lock prefix, one and two processes, with
> other global memory operations (note that the lock prefix instructions
> have absorbed the other memory ops)
>
> mode 5 37.64 ns/loop nproc=1 lcks=no
> mode 6 89.28 ns/loop nproc=2 lcks=no
> mode 7 88.32 ns/loop nproc=1 lcks=yes
> mode 8 161.08 ns/loop nproc=2 lcks=yes
>
> My conclusion from this is that the lock protocols have a general case
> overhead of 50 to 80 nS on a duel P-III/450 system. I don't think it
> would be noticeable.
Just as another data point, it would be interesting to see the overhead
for non-inline versions (i.e. functions in the kernel which are using lock
or not called by code in loaded modules).
The alpha versions of these operations are already non-inline since it
takes quite a few instructions to implement them.
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
