Date: Sun, 26 Dec 2010 15:20:50 +0100 From: Ivan Voras <ivoras@freebsd.org> To: Gleb Kurtsou <gleb.kurtsou@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: [rfc] Replacing FNV and hash32 with Paul Hsieh's SuperFastHash Message-ID: <AANLkTinBJnWfTijL3LSfa8MQV%2BbGPG67euDgT1uG56rD@mail.gmail.com> In-Reply-To: <20101226132431.GA16490@tops> References: <20101223224619.GA21984@tops> <if5gmr$a5r$1@dough.gmane.org> <20101226132431.GA16490@tops>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26 December 2010 14:24, Gleb Kurtsou <gleb.kurtsou@gmail.com> wrote: > On (25/12/2010 20:29), Ivan Voras wrote: >> On 23.12.2010 23:46, Gleb Kurtsou wrote: >> >> > For testing I've used dbench with 16 processes on 1 Gb swap back md >> > device, UFS + SoftUpdates: >> > Old hash (Mb/s): 599.94 =C2=A0600.096 599.536 >> > SFH hash (Mb/s): 612.439 612.341 609.673 >> > >> > It's just ~1% improvement, but dbench is not a VFS metadata intensive >> > benchmark. Subjectively it feels faster accessing maildir mailboxes >> > with ~10.000 messages : ) >> >> Try blogbench if you need metadata-intensive operations, or even fsx. > blogbench should be good, but I've always had hard time interpreting its > results. Besides results tend to very a lot, there is no way to set seed > value like in fsx, so that I could run exactly the same test in different > configurations. I think the exact sequence of blogbench operations depends on duration of previous operations (it's multithreaded) so from that angle you are right - you can't do a repeatable run except in the trivial cases. On the other hand, it uses rand() without seeding it with srand()/sranddev() so this part is actually very repeatable :) > fsx is a different beast, it reads/writes/truncates at random offsets - > great tool for debugging mmap/truncate issues. Patch doesn't improve it > in any way. It depends on what metadata operations you require - blogbench will create, find and write files (if we ignore atime); fsx will create a decent amount of traffic with file size and mtime changes. In your case you'll probably need to run it on a memory file system or tmpfs due to sensitivity to disk IO latencies (if your improvements is on the order of few percent).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinBJnWfTijL3LSfa8MQV%2BbGPG67euDgT1uG56rD>