Tune gencache a bit

[Ira Cooper]

Comments on review:

This will impose an extra read on all writes.  Now is that a big deal?  It
depends on what you are stalling on.  The syncs or fcntl locks.  On fcntl
locks it could hurt, because you could be doubling up your tdb use on write.

But if the patch removes a large number of the writes.... And for the other
cases the writes are so infrequent, nobody may care in reality.

The only other comment is that I'd probably roll the two additional_time
ifs together, because in my mind they are really testing the same
condition.  But that is SO in the weeds it doesn't matter.  (I wouldn't
make the comment if I wasn't commenting on a real issue.)

I'd have to test this locally, but I doubt our workloads stress gencache
enough to matter.

You noted losing gencache_nosync.tdb on boot, is it worth repopulating, in
your use case?  (I'm not sure if we'd corrupt it or not.)

-Ira

On Tue, Nov 27, 2012 at 8:18 AM, Volker Lendecke
<Volker.Lendecke at sernet.de>wrote:

> On Fri, Nov 23, 2012 at 03:26:20PM +0100, Volker Lendecke wrote:
> > Hi!
> >
> > Recently I came across a workload where we were writing the
> > same value into gencache over and over again. This led to a
> > significant slowdown due to the frequent transaction_commit
> > calls doing msync and fsync syscalls.
> >
> > The attached patchset reduces this workload. We do not write
> > into the cache if we write the same value, extending the
> > remaining cache time by less than 10%.
> >
> > Comments?
>
> Attached find a new patchset with some comments of Christian
> Ambach taken care of.
>
> Thanks,
>
> Volker
>
> --
> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> phone: +49-551-370000-0, fax: +49-551-370000-9
> AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
> http://www.sernet.de, mailto:kontakt at sernet.de
>