linux-kernel - fsync/MAP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Mar 2008 13:12:16 -0700
From:	Brian Harring <ferringb@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: fsync/MAP_SHARED slowdown

Back in 09/2006, rev d08b3851da41d0ee60851f2c75b118e1f7a5fc89 
(discussion at http://lkml.org/lkml/2006/6/19/245) was commited with 
the purpose enabling tracking of shared dirty pages.

Still trying to identify exactly why, but that specific rev results in 
a ~3x slowdown in fsync speed for an app of ours- an isolated test 
case demonstrating it is attached.

To test it, 
gcc -c fsync-test.c -o fsync-test && \
./fsync-test -npages=25600 -seed=0xbae03dae -keep

We've tested it across a fairly wide set of amd64 machines, 248/254's, 
all SMP.  IO rates of the machines does have an affect on the results, 
but doesn't seem to change the 3x shift after that rev was merged so 
likely isn't relevant.

Our testing has been w/ >=8gb systems, although should be able to 
reproduce it on 2gb.

Any suggestions?  The increase in page faults is expected, but I'm not 
seeing how that would lead to fsync itself becoming 3x slower for this 
usage scenario.

Please cc me for responses-
thanks,
~brian

View attachment "fsync-test.c" of type "text/x-csrc" (17812 bytes)