bloom: avoid kernel disk flushes when we dirty a lot of pages.

bloom: avoid kernel disk flushes when we dirty a lot of pages.

Based on the number of objects we'll add to the bloom, decide if we want to
mmap() the pages as shared-writable ('immediate' write) or else map them
private-writable for later manual writing back to the file ('delayed'
write).

A bloom table's write access pattern is such that we dirty almost all the
pages after adding very few entries; essentially, we can expect to dirty
about n*k/4096 pages if we add n objects to the bloom with k hashes. But the
table is so big that dirtying *all* the pages often exceeds Linux's default
/proc/sys/vm/dirty_ratio or /proc/sys/vm/dirty_background_ratio,
thus causing it to start flushing the table before we're
finished... even though there's more than enough space to
store the bloom table in RAM.

To work around that behaviour, if we calculate that we'll probably end up
touching the whole table anyway (at least one bit flipped per memory page),
let's use a "private" mmap, which defeats Linux's ability to flush it to
disk.  Then we'll flush it as one big lump during close(), which doesn't
lose any time since we would have had to flush all the pages anyway.

While we're here, let's remove the readwrite=True option to
ShaBloom.create(); nobody's going to create a bloom file that isn't
writable.

Signed-off-by: Avery Pennarun <apenwarr@gmail.com>