On Tue, 9 Oct 2012 16:21:24 -0700 (PDT) Hugh Dickins <hughd@xxxxxxxxxx> wrote: > > > > I am seriously tempted to switch to pure software dirty bits by using > > page protection for writable but clean pages. The worry is the number of > > additional protection faults we would get. But as we do software dirty > > bit tracking for the most part anyway this might not be as bad as it > > used to be. > > That's exactly the same reason why tmpfs opts out of dirty tracking, fear > of unnecessary extra faults. Anomalous as s390 is here, tmpfs is being > anomalous too, and I'd be a hypocrite to push for you to make that change. I tested the waters with the software dirty bit idea. Using kernel compile as test case I got these numbers: disk backing, swdirty: 10,023,870 minor-faults 18 major-faults disk backing, hwdirty: 10,023,829 minor-faults 21 major-faults tmpfs backing, swdirty: 10,019,552 minor-faults 49 major-faults tmpfs backing, hwdirty: 10,032,909 minor-faults 81 major-faults That does not look bad at all. One test I found that shows an effect is lat_mmap from LMBench: disk backing, hwdirty: 30,894 minor-faults 0 major-faults disk backing, swdirty: 30,894 minor-faults 0 major-faults tmpfs backing, hwdirty: 22,574 minor-faults 0 major-faults tmpfs backing, swdirty: 36,652 minor-faults 0 major-faults The runtime between the hwdirty vs. the swdirty setup is very similar, encouraging enough for me to ask our performance team to run a larger test. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
