[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1327831380.14602.6.camel@edumazet-laptop>
Date: Sun, 29 Jan 2012 11:03:00 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Wu Fengguang <wfg@...ux.intel.com>
Cc: Herbert Poetzl <herbert@...hfloor.at>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Jens Axboe <axboe@...nel.dk>, Tejun Heo <tj@...nel.org>
Subject: Re: Bad SSD performance with recent kernels
Le dimanche 29 janvier 2012 à 13:59 +0800, Wu Fengguang a écrit :
> What's the block size? If it's < 4k, performance might be hurt.
>
> blockdev --getbsz /dev/sda
>
# blockdev --getbsz /dev/sda
4096
> > FYI, I started a bisection.
>
> Thank you! If the bisection would take much human time, it should be
> easier to collect some blktrace data on reading /dev/sda for analyzes.
>
Very strange, my bissection ended on following commit :
commit 805f6b5e1cbfedfb9b3d354013e7f4b13a79270f
Author: Tao Ma <boyu.mt@...bao.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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists