Switch pfil(9) to rmlocks

[Max Laier]

On Saturday 24 November 2007, Kris Kennaway wrote:
> 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?

I don't think so.  It's a scheduling problem, but one you can't (easily) 
predict.  The gain comes from reduced congestion after one thread is 
done, which doesn't happen in real world situations.  You are never done.  
The only way to reduce congestion is to shrink critical sections and to 
use read locks whenever possible.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20071124/a5f57e65/attachment.pgp