From: Andrea Arcangeli <andrea@suse.de>
To: mgross <mgross@unix-os.sc.intel.com>
Cc: "Griffiths, Richard A" <richard.a.griffiths@intel.com>,
"'Andrew Morton'" <akpm@zip.com.au>,
"'Marcelo Tosatti'" <marcelo@conectiva.com.br>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
"'Carter K. George'" <carter@polyserve.com>,
"'Don Norton'" <djn@polyserve.com>,
"'James S. Tybur'" <jtybur@polyserve.com>,
"Gross, Mark" <mark.gross@intel.com>
Subject: Re: fsync fixes for 2.4
Date: Wed, 17 Jul 2002 22:05:35 +0200 [thread overview]
Message-ID: <20020717200535.GP19553@dualathlon.random> (raw)
In-Reply-To: <200207171735.g6HHZUP28835@unix-os.sc.intel.com>
On Wed, Jul 17, 2002 at 10:44:18AM -0400, mgross wrote:
> On Monday 15 July 2002 06:07 am, Andrea Arcangeli wrote:
> > On Fri, Jul 12, 2002 at 02:52:11PM -0700, Griffiths, Richard A wrote:
> > > Mark is off climbing Mt. Hood, so he asked me to post the data on the
> > > fsync patch.
>
> I was excited to report the significant improvement of 2.4.19rc1+fsync fix
> over 2.4.18 and didn't realize that the improvement was not due to the fsync
> patch. I'm so glad Richard did a careful check, I was on my way out the
> door for my vacation :)
>
> I would like to know what's so good about 2.4.19rc1 that gives our block I/O
> benchmark that significant improvement over 2.4.18.
that should be the effect of the first part of my vm updates that gone into 2.4.19pre.
> > > It appears from these results that there is no appreciable improvement
> > > using the
> > > fsync patch - there is a slight loss of top end on 4 adapters 1 drive.
> >
> > that's very much expected, as said with my new design by adding an
> > additional pass (third pass), I could remove the slight loss that I
> > expected from the simple patch that puts wait_on_buffer right in the
> > first pass.
> >
> > I mentioned this in my first email of the thread, so it looks all right.
> > For a rc2 the slight loss sounds like the simplest approch.
> >
> > If you care about it, with my new fsync accounting design we can fix it,
> > just let me know if you're interested about it. Personally I'm pretty
> > much fine with it this way too, as said in the first email if we block
> > it's likely bdflush is pumping the queue for us. the slowdown is most
> > probably due too early unplug of the queue generated by the blocking
> > points.
>
> I don't care about the very slight (and possibly in the noise floor of our
> test) reduction in throughput due to the fsync fix. I think your's and
> Andrews' assertion of the bdflush / dirty page handling getting stopped up
> is likely the problem preventing scaling to my personal goal of 250 to
> 300MB/sec on our setup.
yep, should be. Actually running multiple fsyncs from multiple tasks
will kind of workaround the single threaded async flushing of 2.4.
>
> Thanks,
>
> Mark Gross
> PS I had a very nice time on mount hood. I didn't make it to the top this
> time too much snow had melted off the top of the thing to have a safe attempt
> at the summit. It was a guided (http://www.timberlinemtguides.com) 3 day
> climb.
:)
Andrea
next prev parent reply other threads:[~2002-07-17 20:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-12 21:52 fsync fixes for 2.4 Griffiths, Richard A
2002-07-12 22:21 ` Andrew Morton
2002-07-15 10:07 ` Andrea Arcangeli
2002-07-15 18:36 ` Andrew Morton
2002-07-17 14:44 ` mgross
2002-07-17 20:05 ` Andrea Arcangeli [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-07-10 20:20 Andrea Arcangeli
2002-07-11 20:21 ` Marcelo Tosatti
2002-07-11 22:57 ` Andrea Arcangeli
2002-07-12 0:51 ` Marcelo Tosatti
2002-07-12 1:52 ` Andrea Arcangeli
2002-07-12 2:59 ` Marcelo Tosatti
2002-07-11 21:57 ` J.A. Magallon
2002-07-11 23:00 ` Andrea Arcangeli
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=20020717200535.GP19553@dualathlon.random \
--to=andrea@suse.de \
--cc=akpm@zip.com.au \
--cc=carter@polyserve.com \
--cc=djn@polyserve.com \
--cc=jtybur@polyserve.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=mark.gross@intel.com \
--cc=mgross@unix-os.sc.intel.com \
--cc=richard.a.griffiths@intel.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.