Switch pfil(9) to rmlocks
max at love2party.net
Sun Nov 25 01:46:35 PST 2007
On Sunday 25 November 2007, Darren Reed 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
> Is that 13%/5%/35% faster or slower or improvement or degradation?
> If "rw hook" (using rwlock like we have today?) is 5%, whas is the
> I'm expecting that at least one of these should be a 0%...
Sorry for the sparse explanation. All numbers above are gain with rmlocks
i.e. rmlocks are faster in all scenarios. The test cases are different
hook functions. Every hook has a DELAY(1) and a lock/unlock call around
it of the respective lock type. read lock acquisitions for rw and rm.
Please look at the code I posted a bit later for more details.
/"\ 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
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20071125/0a7efeeb/attachment.pgp
More information about the freebsd-current