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