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

Jeff Johnson notifications at github.com
Fri Apr 14 18:42:02 UTC 2017


Here are some measurements (on RPM5, but its essentially the same implementation).

The system is Fedora 25, the disk is 7200rpm rotating media, dual 4 core xeons, etc.

The System.map file in the current RawHide kernel-core file was used to measure the time taken by the various system calls involved which were summed using the ramie/rpmsw.c "stop watch" (which uses rdtsc and has nsec precision and at least usec accuracy).

BASE == RPM before enabling I/O tweaks
O_SYNC == write files opened with O_SYNC
O_DSYNC == write files opened with O_DSYNC

fallocate,fdatasync,fadvise,fsync were enabled as in the patch on this thread

The measurements should be taken nominally: no effort was made to reproduce, or control for other system load, etc, etc.

`
BASE
====================================
 FDIO:      30 writes,  3763601 total bytes in 0.004301 secs

BASE+O_SYNC
====================================
 FDIO:      30 writes,  3763601 total bytes in 1.320981 secs

BASE+O_DSYNC
====================================
 FDIO:      30 writes,  3763601 total bytes in 3.115997 secs

BASE+fdatasync+fasdvise+fsync
====================================
 FDIO:      30 writes,  3763601 total bytes in 0.005069 secs
 FDIO:      15 dsyncs,        0 total bytes in 0.730461 secs
 FDIO:       1  syncs,        0 total bytes in 0.005501 secs


BASE+fallocate+fdatasync+fadvise+fsync
====================================
 FDIO:      30 writes,  3763601 total bytes in 0.003941 secs
 FDIO:       1 allocs,  3763601 total bytes in 0.000026 secs
 FDIO:      15 dsyncs,        0 total bytes in 0.703922 secs
 FDIO:       1  syncs,        0 total bytes in 0.005535 secs

`

So the best case is ~170x slower, and the worst case is ~725x slower, than just using the kernel caches. Again, these numbers should be taken nominally etc etc etc

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/187#issuecomment-294211495
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170414/d73eb9be/attachment.html>


More information about the Rpm-maint mailing list