Re: [PATCH] mm: Fix XFS oops due to dirty pages without buffers ons390
From: Martin Schwidefsky
Date: Fri Oct 19 2012 - 10:38:18 EST
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.
"Reality continues to ruin my life." - Calvin.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/