Switch pfil(9) to rmlocks

[Kris Kennaway]

Max Laier wrote:
> On Friday 23 November 2007, Robert Watson wrote:
>> On Fri, 23 Nov 2007, Max Laier wrote:
>>> attached is a diff to switch the pfil(9) subsystem to rmlocks, which
>>> are more suited for the task.  I'd like some exposure before doing
>>> the switch, but I don't expect any fallout.  This email is going
>>> through the patched pfil already - twice.
>> Max,
>>
>> Have you done performance measurements that show rmlocks to be a win in
>> this scenario?  I did some patchs for UNIX domain sockets to replace
>> the rwlock there but it appeared not to have a measurable impact on SQL
>> benchmarks, presumbaly because the read/write blend wasn't right and/or
>> that wasnt a significant source of overhead in the benchmark.  I'd
>> anticipate a much more measurable improvement for pfil, but would be
>> interested in learning how much is seen?
> 
> I had to roll an artificial benchmark in order to see a significant change 
> (attached - it's a hack!).
> 
> Using 3 threads on a 4 CPU machine I get the following results:
> null hook: ~13% +/- 2
> mtx hook: up to 40% [*]
> rw hook: ~5% +/- 1
> rm hook: ~35% +/- 5
> 
> [*] The mtx hook is inconclusive as my measurements vary a lot.  If one 
> thread gets lucky and keeps running the overall time obviously goes down 
> by a magnitude.  It seems however, that rmlocks greatly increase the 
> chance of that happening - not sure if that's a good thing, though.  If 
> all threads receive approximately equal runtime (which is almost always 
> the case for rwlocks) the difference is somewhere around 10%.

Is that something we can try to arrange to happen for improved 
performance in more general situations?

Kris