* something is dramatically wrong with buffered read performance in 2.6.32.9
@ 2010-03-17 22:33 Stan Hoeppner
0 siblings, 0 replies; only message in thread
From: Stan Hoeppner @ 2010-03-17 22:33 UTC (permalink / raw)
To: linux-ide
I recently upgraded from kernel 2.6.31.1 to 2.6.32.9. Upon kicking the
tires on the new kernel I discovered that my two data partitions are
suffering a ~30MB/s performance loss compared to my root partition. That's
a loss of nearly half the performance of my disk.
The root partition is a primary, formatted with EXT2. The two data
partitions are logicals within an extended partition, both formatted with
XFS. hdparm O_DIRECT tests show identical throughput for all 3 partitions.
Going through the buffer cache, however, shows a huge performance drop for
the two logical partitions. Throughput is nearly cut in half through the
buffer cache:
/dev/sda2:
Timing O_DIRECT disk reads: 238 MB in 3.02 seconds = 78.79 MB/sec
/dev/sda2:
Timing buffered disk reads: 208 MB in 3.00 seconds = 69.26 MB/sec
/dev/sda6:
Timing O_DIRECT disk reads: 236 MB in 3.02 seconds = 78.14 MB/sec
/dev/sda6:
Timing buffered disk reads: 126 MB in 3.01 seconds = 41.79 MB/sec
/dev/sda7:
Timing O_DIRECT disk reads: 238 MB in 3.00 seconds = 79.27 MB/sec
/dev/sda7:
Timing buffered disk reads: 126 MB in 3.03 seconds = 41.65 MB/sec
Any ideas what I'm running into here? Did I somehow fubar something in
menuconfig?
I get the same results with dd copy tests through the buffer cache to
/dev/null. Any idea what's wrong? Is this a known bug?
--
Stan
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2010-03-17 22:33 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-17 22:33 something is dramatically wrong with buffered read performance in 2.6.32.9 Stan Hoeppner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).