From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Hugh Dickins <hughd@google.com>
Cc: linux-s390@vger.kernel.org, Jan Kara <jack@suse.cz>,
LKML <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, linux-mm@kvack.org, Mel Gorman <mgorman@suse.de>
Subject: Re: [PATCH] mm: Fix XFS oops due to dirty pages without buffers on s390
Date: Fri, 19 Oct 2012 16:38:14 +0200 [thread overview]
Message-ID: <20121019163814.55b3590e@mschwide> (raw)
In-Reply-To: <alpine.LSU.2.00.1210091600450.30446@eggly.anvils>
On Tue, 9 Oct 2012 16:21:24 -0700 (PDT)
Hugh Dickins <hughd@google.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.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Hugh Dickins <hughd@google.com>
Cc: Jan Kara <jack@suse.cz>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, Mel Gorman <mgorman@suse.de>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH] mm: Fix XFS oops due to dirty pages without buffers on s390
Date: Fri, 19 Oct 2012 16:38:14 +0200 [thread overview]
Message-ID: <20121019163814.55b3590e@mschwide> (raw)
In-Reply-To: <alpine.LSU.2.00.1210091600450.30446@eggly.anvils>
On Tue, 9 Oct 2012 16:21:24 -0700 (PDT)
Hugh Dickins <hughd@google.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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Hugh Dickins <hughd@google.com>
Cc: Jan Kara <jack@suse.cz>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, Mel Gorman <mgorman@suse.de>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH] mm: Fix XFS oops due to dirty pages without buffers on s390
Date: Fri, 19 Oct 2012 16:38:14 +0200 [thread overview]
Message-ID: <20121019163814.55b3590e@mschwide> (raw)
In-Reply-To: <alpine.LSU.2.00.1210091600450.30446@eggly.anvils>
On Tue, 9 Oct 2012 16:21:24 -0700 (PDT)
Hugh Dickins <hughd@google.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.
next prev parent reply other threads:[~2012-10-19 14:36 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-01 16:26 [PATCH] mm: Fix XFS oops due to dirty pages without buffers on s390 Jan Kara
2012-10-01 16:26 ` Jan Kara
2012-10-01 16:26 ` Jan Kara
2012-10-08 14:28 ` Mel Gorman
2012-10-08 14:28 ` Mel Gorman
2012-10-08 14:28 ` Mel Gorman
2012-10-09 4:24 ` Hugh Dickins
2012-10-09 4:24 ` Hugh Dickins
2012-10-09 4:24 ` Hugh Dickins
2012-10-09 8:18 ` Martin Schwidefsky
2012-10-09 8:18 ` Martin Schwidefsky
2012-10-09 8:18 ` Martin Schwidefsky
2012-10-09 23:21 ` Hugh Dickins
2012-10-09 23:21 ` Hugh Dickins
2012-10-09 23:21 ` Hugh Dickins
2012-10-10 21:57 ` Hugh Dickins
2012-10-10 21:57 ` Hugh Dickins
2012-10-10 21:57 ` Hugh Dickins
2012-10-19 14:38 ` Martin Schwidefsky [this message]
2012-10-19 14:38 ` Martin Schwidefsky
2012-10-19 14:38 ` Martin Schwidefsky
2012-10-09 9:32 ` Mel Gorman
2012-10-09 9:32 ` Mel Gorman
2012-10-09 9:32 ` Mel Gorman
2012-10-09 23:00 ` Hugh Dickins
2012-10-09 23:00 ` Hugh Dickins
2012-10-09 23:00 ` Hugh Dickins
2012-10-09 16:21 ` Jan Kara
2012-10-09 16:21 ` Jan Kara
2012-10-09 16:21 ` Jan Kara
2012-10-10 2:19 ` Hugh Dickins
2012-10-10 2:19 ` Hugh Dickins
2012-10-10 2:19 ` Hugh Dickins
2012-10-10 8:55 ` Jan Kara
2012-10-10 8:55 ` Jan Kara
2012-10-10 8:55 ` Jan Kara
2012-10-10 21:28 ` Hugh Dickins
2012-10-10 21:28 ` Hugh Dickins
2012-10-10 21:28 ` Hugh Dickins
2012-10-11 7:42 ` Martin Schwidefsky
2012-10-11 7:42 ` Martin Schwidefsky
2012-10-11 7:42 ` Martin Schwidefsky
2012-10-10 21:56 ` Dave Chinner
2012-10-10 21:56 ` Dave Chinner
2012-10-10 21:56 ` Dave Chinner
2012-10-11 7:44 ` Martin Schwidefsky
2012-10-11 7:44 ` Martin Schwidefsky
2012-10-11 7:44 ` Martin Schwidefsky
2012-10-17 0:43 ` Jan Kara
2012-10-17 0:43 ` Jan Kara
2012-10-17 0:43 ` Jan Kara
-- strict thread matches above, loose matches on Subject: below --
2012-10-22 15:06 Jan Kara
2012-10-22 19:38 ` Andrew Morton
2012-10-23 4:40 ` Hugh Dickins
2012-10-23 10:21 ` Jan Kara
2012-10-23 21:56 ` Andrew Morton
2012-10-24 8:30 ` Martin Schwidefsky
2012-10-25 20:01 ` Jan Kara
2012-12-14 8:45 ` Martin Schwidefsky
2012-12-17 23:31 ` Hugh Dickins
2012-12-18 7:30 ` Martin Schwidefsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121019163814.55b3590e@mschwide \
--to=schwidefsky@de.ibm.com \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.