[rfc] Replacing FNV and hash32 with Paul Hsieh's SuperFastHash

[Ivan Voras]

On 26 December 2010 14:24, Gleb Kurtsou <gleb.kurtsou at 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  600.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).