Re: Switch pfil(9) to rmlocks

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@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
    ... 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)
  • 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)
  • 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-net)