Re: Switch pfil(9) to rmlocks

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
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Switch pfil(9) to rmlocks
    ... the rwlock there but it appeared not to have a measurable impact on SQL ... that wasnt a significant source of overhead in the benchmark. ... I had to roll an artificial benchmark in order to see a significant change. ... The mtx hook is inconclusive as my measurements vary a lot. ...
    (freebsd-net)
  • Re: Switch pfil(9) to rmlocks
    ... the rwlock there but it appeared not to have a measurable impact on SQL ... that wasnt a significant source of overhead in the benchmark. ... I had to roll an artificial benchmark in order to see a significant change ... The mtx hook is inconclusive as my measurements vary a lot. ...
    (freebsd-current)
  • Re: Switch pfil(9) to rmlocks
    ... the rwlock there but it appeared not to have a measurable impact on SQL ... that wasnt a significant source of overhead in the benchmark. ... I had to roll an artificial benchmark in order to see a significant change ... The mtx hook is inconclusive as my measurements vary a lot. ...
    (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
    ... 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)