From: Andrew Morton <akpm@digeo.com>
To: Hirokazu Takahashi <taka@valinux.co.jp>
Cc: linux-kernel@vger.kernel.org, janetmor@us.ibm.com
Subject: Re: [patch] readv/writev rework
Date: Thu, 12 Sep 2002 20:31:16 -0700 [thread overview]
Message-ID: <3D815C04.A08CB5D9@digeo.com> (raw)
In-Reply-To: 20020913.101826.32726068.taka@valinux.co.jp
Hirokazu Takahashi wrote:
>
> Hello,
>
> > > Your readv/writev patch interested me and I checked it.
> > > I found we also have a chance to improve normal writev.
> > >
> > > a_ops->prepare_write() and a_ops->commit_write will have a
> > > penalty when I/O size isn't PAGE_SIZE.
> > > With following patch generic_file_write_nolock() will try to
> > > make each I/O size become PAGE_SIZE.
> > >
> >
> > Certainly makes a lot of sense. If an application has a large
> > number of small objects which are to be appended to a file, and
> > they are not contiguous in user memory then this patch makes
> > writev() a very attractive way of doing that. Tons faster.
I wrote a little app which simulates a text editor writing out
its buffer. Just:
struct line {
char *data;
int length;
struct line *next;
};
walk this linked list, writing the lines out. The input was
`cat linux/kernel/*.c > inputfile' and the output was written
1000 times (300 megs). Benched four different ways of writing the
output:
2.5.34 2.5.34-mm2 2.5.34-mm2-taka
write 54s 54s 55s
fwrite 12.8s 12.8s 12.7s
fwrite_unlocked 11.6s 11.6s 11.5s
writev 39s 33.4s 15.8s
So Janet's patch made a 15% improvement with this test. Yours
dropped it 50% again.
> Yeah, I realized syslogd is using writev against logfiles which are
> opened with O_SYNC flag! I think heavy loaded mail-servers or
> web-servers may get good performance with the new writev
> as they are logging too much.
O_SYNC writev? Ooh, oww, that hurts...
With 2.5.34, writing the 300k file once (1000x less data than above)
with 1024-vector writev's, opened O_SYNC: 68 seconds.
With 2.5.34-mm2-taka the same write takes 0.23 seconds. (I had to write
100x as much data just to get a measurement).
A 300x speedup is nice, but based on these numbers syslogd should be
using fwrite_unlocked() and fflush().
O_SYNC should be eradicated. It's basically always the wrong thing
to do. Applications should write as much stuff as they can and then
run fsync.
>
> It sounds nice.
> I'll rewrite it soon.
>
Great. The test app is at http://www.zip.com.au/~akpm/writev-speed.c
next prev parent reply other threads:[~2002-09-13 3:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-11 8:30 [patch] readv/writev rework Andrew Morton
2002-09-12 13:00 ` Hirokazu Takahashi
2002-09-12 18:47 ` Andrew Morton
2002-09-13 1:18 ` Hirokazu Takahashi
2002-09-13 3:31 ` Andrew Morton [this message]
2002-09-14 4:54 ` Andrew Morton
2002-09-14 7:39 ` Hirokazu Takahashi
2002-09-13 7:22 ` Hirokazu Takahashi
2002-09-13 8:29 ` Andrew Morton
2002-09-13 8:26 ` Hirokazu Takahashi
2002-09-13 9:23 ` Hirokazu Takahashi
2002-09-13 17:43 ` Andrew Morton
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=3D815C04.A08CB5D9@digeo.com \
--to=akpm@digeo.com \
--cc=janetmor@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=taka@valinux.co.jp \
/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.