[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20121019163814.55b3590e@mschwide>
Date: Fri, 19 Oct 2012 16:38:14 +0200
From: Martin Schwidefsky <schwidefsky@...ibm.com>
To: Hugh Dickins <hughd@...gle.com>
Cc: Jan Kara <jack@...e.cz>, linux-mm@...ck.org,
LKML <linux-kernel@...r.kernel.org>, xfs@....sgi.com,
Mel Gorman <mgorman@...e.de>, linux-s390@...r.kernel.org
Subject: Re: [PATCH] mm: Fix XFS oops due to dirty pages without buffers on
s390
On Tue, 9 Oct 2012 16:21:24 -0700 (PDT)
Hugh Dickins <hughd@...gle.com> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists