[Rpm-maint] [rpm-software-management/rpm] Add macro to force fsync() on close() (#187)

Jeff Johnson notifications at github.com
Sat Apr 8 14:17:00 UTC 2017

Thanks for measurements! Could you also attempt to measure the effect on RPM too? Wall clock time is sufficient, as the time necessary to perform an upgrade is what most RPM users are sensitive to.

Your graphs (presumably on SSD?) show smaller/periodic writes w fsync enabled,
and larger/delayed writes w/o fsync, as expected. The delay (most obvious w/o sync, but occasionally w fsync(2)) is part of the cache flush algorithm to prevent active writes from starving reads (i.e. your database stalls).

The issue (for RPM) is that fwrite(2)+fsync(2) ends with a  blocking system call, while mmap(2)+madvise(MADV_DONTNEED)+msync(MS_ASYNC) permits RPM to continue running while the cache is flushed and resources are free'd. By continuing to run, RPM can provide more information on RPM near term write needs to the kernel cache flushing scheduler. The end result in both cases is that resources used by RPM write's are free'd as soon as possible.

Does that explanation make sense to you? I'll try to get a patch to (again) use mmap+madvise+msync for rpm.org together this weekend.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170408/fd72da59/attachment.html>

More information about the Rpm-maint mailing list