From: Zach Brown <zach.brown@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Arjan van de Ven <arjan@infradead.org>,
Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@zip.com.au>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Ulrich Drepper <drepper@redhat.com>,
Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
"David S. Miller" <davem@davemloft.net>,
Suparna Bhattacharya <suparna@in.ibm.com>,
Davide Libenzi <davidel@xmailserver.org>,
Jens Axboe <jens.axboe@oracle.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Syslets, Threadlets, generic AIO support, v6
Date: Tue, 29 May 2007 15:49:16 -0700 [thread overview]
Message-ID: <20070529224916.GK7875@mami.zabbo.net> (raw)
In-Reply-To: <alpine.LFD.0.98.0705291447440.26602@woody.linux-foundation.org>
> .. so don't keep us in suspense. Do you have any numbers for anything
> (like Oracle, to pick a random thing out of thin air ;) that might
> actually indicate whether this actually works or not?
I haven't gotten to running Oracle's database against it. It is going
to be Very Cranky if O_DIRECT writes aren't concurrent, and that's going
to take a bit of work in fs/direct-io.c.
I've done initial micro-benchmarking runs for basic sanity testing with
fio. They haven't wildly regressed, that's about as much as can be said
with confidence so far :).
Take a streaming O_DIRECT read. 1meg requests, 64 in flight.
str: (g=0): rw=read, bs=1M-1M/1M-1M, ioengine=libaio, iodepth=64
mainline:
read : io=3,405MiB, bw=97,996KiB/s, iops=93, runt= 36434msec
aio+syslets:
read : io=3,452MiB, bw=99,115KiB/s, iops=94, runt= 36520msec
That's on an old gigabit copper FC array with 10 drives behind a, no
seriously, qla2100.
The real test is the change in memory and cpu consumption, and I haven't
modified fio to take reasonably precise measurements of those yet. Once
I get O_DIRECT writes concurrent that'll be the next step.
I was pleased to see my motivation for the patches, to avoid having to
add specific support for operations to be called from fs/aio.c, work
out.
Take the case of 4k random buffered reads from a block device with a
cold cache:
read: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
mainine:
read : io=16,116KiB, bw=457KiB/s, iops=111, runt= 36047msec
slat (msec): min= 4, max= 629, avg=563.17, stdev=71.92
clat (msec): min= 0, max= 0, avg= 0.00, stdev= 0.00
aio+syslets:
read : io=125MiB, bw=3,634KiB/s, iops=887, runt= 36147msec
slat (msec): min= 0, max= 3, avg= 0.00, stdev= 0.08
clat (msec): min= 2, max= 643, avg=71.59, stdev=74.25
aio+syslets w/o cfq
read : io=208MiB, bw=6,057KiB/s, iops=1,478, runt= 36071msec
slat (msec): min= 0, max= 15, avg= 0.00, stdev= 0.09
clat (msec): min= 2, max= 758, avg=42.75, stdev=37.33
Everyone step back and thank Jens for writing a tool that gives us
interesting data without us always having to craft some stupid specific
test each and every time. Thanks, Jens!
In the mainline number fio clearly shows the buffered read submissions
being handled synchronously. The mainline buffered IO paths doesn't
know to identify and work with iocbs so requests are handled in series.
In the +syslet number we see the __async_schedule() catching
the blocking buffered read, letting the submission proceed
asynchronously. We get async behaviour without having to touch any of
the buffered IO paths.
Then we turn off cfq and we actually start to saturate the (relatively
ancient) drives :).
I need to mail Jens about that cfq behaviour, but I'm guessing it's
expected behaviour of a sort -- each syslet thread gets its own
io_context instead of inheriting it from its parent.
- z
next prev parent reply other threads:[~2007-05-29 22:51 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-29 21:27 Zach Brown
2007-05-29 21:49 ` Linus Torvalds
2007-05-29 22:49 ` Zach Brown [this message]
2007-05-29 22:16 ` Jeff Garzik
2007-05-29 23:09 ` Zach Brown
2007-05-29 23:20 ` Ulrich Drepper
2007-05-30 1:11 ` Dave Jones
2007-05-30 17:08 ` Zach Brown
2007-05-30 7:26 ` Ingo Molnar
2007-05-30 7:20 ` Ingo Molnar
2007-05-30 7:31 ` Ulrich Drepper
2007-05-30 8:42 ` Ingo Molnar
2007-05-30 8:51 ` Evgeniy Polyakov
2007-05-30 9:05 ` Ingo Molnar
2007-05-30 15:16 ` Linus Torvalds
2007-05-30 15:39 ` Ulrich Drepper
2007-05-30 19:40 ` Davide Libenzi
2007-05-30 19:55 ` Ulrich Drepper
2007-05-30 20:00 ` Linus Torvalds
2007-05-30 20:21 ` Davide Libenzi
2007-05-30 20:31 ` Eric Dumazet
2007-05-30 20:44 ` Linus Torvalds
2007-05-30 21:53 ` Eric Dumazet
2007-05-30 21:31 ` Davide Libenzi
2007-05-30 21:16 ` Ulrich Drepper
2007-05-30 21:27 ` Linus Torvalds
2007-05-30 21:47 ` Ulrich Drepper
2007-05-30 22:06 ` Davide Libenzi
2007-05-30 21:48 ` Davide Libenzi
2007-05-30 22:01 ` Linus Torvalds
2007-05-31 6:13 ` Ingo Molnar
2007-05-31 7:35 ` Eric Dumazet
2007-05-31 9:26 ` Ingo Molnar
2007-05-31 9:02 ` Ingo Molnar
2007-05-31 10:41 ` Eric Dumazet
2007-05-31 10:50 ` Ingo Molnar
2007-05-31 9:32 ` Ingo Molnar
2007-05-31 9:34 ` Jens Axboe
2007-05-30 22:09 ` Eric Dumazet
2007-05-30 21:51 ` David M. Lloyd
2007-05-30 22:24 ` William Lee Irwin III
2007-05-30 21:38 ` Jeremy Fitzhardinge
2007-05-30 21:39 ` Davide Libenzi
2007-05-30 21:36 ` Jeremy Fitzhardinge
2007-05-30 21:44 ` Linus Torvalds
2007-05-30 21:48 ` Linus Torvalds
2007-05-30 21:54 ` Jeremy Fitzhardinge
2007-05-30 22:27 ` Matt Mackall
2007-05-30 22:38 ` William Lee Irwin III
2007-05-30 8:32 ` Evgeniy Polyakov
2007-05-30 8:54 ` Ingo Molnar
2007-05-30 9:30 ` Evgeniy Polyakov
2007-05-30 9:28 ` Jeff Garzik
2007-05-30 13:02 ` Ingo Molnar
2007-05-30 13:20 ` Ingo Molnar
2007-05-30 15:31 ` Linus Torvalds
2007-05-30 16:09 ` Ingo Molnar
2007-05-30 17:57 ` Jens Axboe
2007-05-30 19:05 ` Mark Lord
2007-05-30 19:10 ` Jens Axboe
2007-05-30 19:15 ` Linus Torvalds
2007-05-30 19:32 ` Jens Axboe
2007-05-30 20:07 ` Eric Dumazet
2007-05-30 20:31 ` Linus Torvalds
2007-05-30 20:46 ` Eric Dumazet
2007-05-30 19:52 ` Davide Libenzi
2007-05-30 7:40 ` Jens Axboe
2007-05-30 16:55 ` Zach Brown
2007-05-30 17:33 ` Jens Axboe
2007-05-31 8:15 Albert Cahalan
2007-05-31 9:50 ` Ingo Molnar
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=20070529224916.GK7875@mami.zabbo.net \
--to=zach.brown@oracle.com \
--cc=akpm@zip.com.au \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=davem@davemloft.net \
--cc=davidel@xmailserver.org \
--cc=drepper@redhat.com \
--cc=hch@infradead.org \
--cc=jens.axboe@oracle.com \
--cc=johnpol@2ka.mipt.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=suparna@in.ibm.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®