Re: Switch pfil(9) to rmlocks

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
baseline?

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@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News

Attachment: signature.asc
Description: This is a digitally signed message part.

Relevant Pages

  • Re: Switch pfil(9) to rmlocks
    ... Have you done performance measurements that show rmlocks to be a ... I had to roll an artificial benchmark in order to see a significant ... If "rw hook" is 5%, ... All numbers above are gain with rmlocks ...
    (freebsd-current)
  • Re: Switch pfil(9) to rmlocks
    ... Have you done performance measurements that show rmlocks to be ... source of overhead in the benchmark. ... If "rw hook" is 5%, ... lock/unlock call around it of the respective lock type. ...
    (freebsd-current)
  • Re: Switch pfil(9) to rmlocks
    ... Have you done performance measurements that show rmlocks to be ... source of overhead in the benchmark. ... If "rw hook" is 5%, ... lock/unlock call around it of the respective lock type. ...
    (freebsd-net)
  • Some initial postmark numbers from a dual-PIII+ATA, 4.x and 6.x
    ... I pulled down the postmark benchmark, and gave it a spin on a dual PIII ... the "alone" measurements, associated with the setup and tear-down of the ... While I didn't attempt to measure precise CPU usage as yet, ...
    (freebsd-performance)
  • Re: Switch pfil(9) to rmlocks
    ... I had to roll an artificial benchmark in order to see a significant ... The mtx hook is inconclusive as my measurements vary a lot. ... performance in more general situations? ... The gain comes from reduced congestion after one thread is ...
    (freebsd-current)