mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: <linux-kernel@vger.kernel.org>
Cc: "Andrew Morton" <akpm@osdl.org>, "'Jens Axboe'" <axboe@suse.de>
Subject: Direct io on block device has performance regression on 2.6.x kernel
Date: Tue, 8 Mar 2005 17:39:41 -0800	[thread overview]
Message-ID: <200503090139.j291dfg16356@unix-os.sc.intel.com> (raw)

I don't know where to start, but let me start with the bombshell:

Direct I/O on block device running 2.6.X kernel is a lot SLOWER
than running on a 2.4 Kernel!


Processing a direct I/O request on 2.6 is taking a lot more cpu
time compare to the same I/O request running on a 2.4 kernel.

The proof: easy.  I started off by having a pseudo disk, a software
disk that has zero access latency.  By hooking this pseudo disk into
the block layer API, I can effectively stress the entire I/O stack
above the block level.  Combined with user level test programs that
simply submit direct I/O in a simple while loop, I can measure how
fast kernel can process these I/O requests.  The performance metric
can be either throughput (# of I/O per second) or per unit of work
(processing time per I/O).  For the data presented below, I'm using
throughput metric (meaning larger number is better performance).
Pay attention to relative percentage as absolute number depends on
platform/CPU that test suite runs on.


			synchronous I/O			AIO
			(pread/pwrite/read/write)	io_submit
2.4.21 based
(RHEL3)		265,122				229,810

2.6.9			218,565				206,917
2.6.10		213,041				205,891
2.6.11		212,284				201,124

>From the above chart, you can see that 2.6 kernel is at least 18%
slower in processing direct I/O (on block device) in the synchronous
path and 10% slower in the AIO path compare to a distributor's 2.4
kernel.  What's worse, with each advance of kernel version, the I/O
path is becoming slower and slower.

Most of the performance regression for 2.6.9 came from dio layer (I
still have to find where the regression came from with 2.6.10 and 2.6.11).
DIO is just overloaded with too many areas to cover.  I think it's better
to break things up a little bit.

For example, by having a set of dedicated functions that do direct I/O
on block device improves the performance dramatically:

			synchronous I/O			AIO
			(pread/pwrite/read/write)	io_submit
2.4.21 based
(RHEL3)		265,122				229,810
2.6.9			218,565				206,917
2.6.9+patches	323,016				268,484

See, we can be actually 22% faster in synchronous path and 17% faster
In the AIO path, if we do it right!

Kernel patch and test suite to follow in the next couple postings.

- Ken





             reply	other threads:[~2005-03-09  1:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-09  1:39 Chen, Kenneth W [this message]
2005-03-09  6:27 ` Andrew Morton
2005-03-09 17:21   ` Chen, Kenneth W
2005-03-09 20:04     ` Andrew Morton
2005-03-09 21:59       ` Chen, Kenneth W
2005-03-09 22:44         ` Andrew Morton
2005-03-10  1:11           ` Chen, Kenneth W
2005-03-10  1:33             ` Andrew Morton
2005-03-10  1:44               ` Chen, Kenneth W
2005-03-10  2:25     ` Andrew Morton
2005-03-10  3:47       ` Chen, Kenneth W
2005-03-10  4:04         ` David Lang
2005-03-10  4:10           ` Andrew Morton
2005-03-10  4:15             ` Direct io on block device has performance regression on 2.6.xkernel David Lang
2005-03-10  4:09         ` Direct io on block device has performance regression on 2.6.x kernel Andrew Morton
2005-03-10 18:31           ` Chen, Kenneth W
2005-03-10 20:30             ` Andrew Morton
2005-03-10 21:42               ` Chen, Kenneth W
2005-03-10 22:01                 ` Andrew Morton
2005-03-10  4:28         ` Andrew Vasquez
2005-03-09  1:53 Chen, Kenneth W
2005-03-09 22:18 Chen, Kenneth W
2005-03-09 23:23 ` Andi Kleen
2005-03-09 23:52   ` Jesse Barnes
2005-03-09 23:52   ` Jesse Barnes
2005-03-10  1:00     ` Chen, Kenneth W
2005-03-10  0:57   ` Chen, Kenneth W
2005-03-10  1:24 Chen, Kenneth W
2005-03-10  2:04 Chen, Kenneth W

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=200503090139.j291dfg16356@unix-os.sc.intel.com \
    --to=kenneth.w.chen@intel.com \
    --cc=akpm@osdl.org \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.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®