From: Wu Fengguang <wfg@linux.intel.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Herbert Poetzl <herbert@13thfloor.at>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>, Jens Axboe <axboe@kernel.dk>,
Tejun Heo <tj@kernel.org>, Li Shaohua <shaohua.li@intel.com>
Subject: Re: Bad SSD performance with recent kernels
Date: Mon, 30 Jan 2012 22:48:21 +0800 [thread overview]
Message-ID: <20120130144821.GA23671@localhost> (raw)
In-Reply-To: <1327831380.14602.6.camel@edumazet-laptop>
On Sun, Jan 29, 2012 at 11:03:00AM +0100, Eric Dumazet wrote:
> Very strange, my bissection ended on following commit :
>
> commit 805f6b5e1cbfedfb9b3d354013e7f4b13a79270f
> Author: Tao Ma <boyu.mt@taobao.com>
> Date: Fri Mar 11 20:11:59 2011 +0100
>
> blktrace: Use rq->cmd_flags directly in blk_add_trace_rq.
>
> This makes no sense.
Yeah, commit 55602dd66f535 ("fs: make generic file read/write
functions plug") looks like the real root cause and should probably
be reverted as a whole. Buffered read/write syscalls are not directly
tied to IO after all (readahead/writeback have the right plug points).
Thanks,
Fengguang
> hdparm uses 2MB block reads, so read_ahead (128KB) is too small for best
> perf
>
> # cat /sys/class/block/sda/queue/read_ahead_kb
> 128
>
> # dd if=/dev/sda of=/dev/null bs=128k
> ^C
> 63744+0 enregistrements lus
> 63743+0 enregistrements écrits
> 8354922496 octets (8,4 GB) copiés, 39,975 s, 209 MB/s
>
> # hdparm -t /dev/sda
>
> /dev/sda:
> Timing buffered disk reads: 510 MB in 3.00 seconds = 169.75 MB/sec
>
> # uname -a
> Linux edumazet-laptop 3.0.0-15-generic #26-Ubuntu SMP Fri Jan 20
> 17:23:00 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>
>
next prev parent reply other threads:[~2012-01-31 0:13 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-27 6:00 Bad SSD performance with recent kernels Herbert Poetzl
2012-01-27 6:44 ` Eric Dumazet
2012-01-28 12:51 ` Wu Fengguang
2012-01-28 13:33 ` Eric Dumazet
2012-01-29 5:59 ` Wu Fengguang
2012-01-29 8:42 ` Herbert Poetzl
2012-01-29 9:28 ` Wu Fengguang
2012-01-29 10:03 ` Eric Dumazet
2012-01-29 11:16 ` Wu Fengguang
2012-01-29 13:13 ` Eric Dumazet
2012-01-29 15:52 ` Pádraig Brady
2012-01-29 16:10 ` Wu Fengguang
2012-01-29 20:15 ` Herbert Poetzl
2012-01-30 11:18 ` Wu Fengguang
2012-01-30 12:34 ` Eric Dumazet
2012-01-30 14:01 ` Wu Fengguang
2012-01-30 14:05 ` Wu Fengguang
2012-01-30 3:17 ` Shaohua Li
2012-01-30 5:31 ` Eric Dumazet
2012-01-30 5:45 ` Shaohua Li
2012-01-30 7:13 ` Herbert Poetzl
2012-01-30 7:22 ` Shaohua Li
2012-01-30 7:36 ` Herbert Poetzl
2012-01-30 8:12 ` Shaohua Li
2012-01-30 10:31 ` Shaohua Li
2012-01-30 14:28 ` Wu Fengguang
2012-01-30 14:51 ` Eric Dumazet
2012-01-30 22:26 ` Vivek Goyal
2012-01-31 0:14 ` Shaohua Li
2012-01-31 1:07 ` Wu Fengguang
2012-01-31 3:00 ` Shaohua Li
2012-01-31 2:17 ` Eric Dumazet
2012-01-31 8:46 ` Eric Dumazet
2012-01-31 6:36 ` Herbert Poetzl
2012-01-30 14:48 ` Wu Fengguang [this message]
2012-01-28 17:01 ` Herbert Poetzl
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=20120130144821.GA23671@localhost \
--to=wfg@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=eric.dumazet@gmail.com \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@intel.com \
--cc=tj@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 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.