On Mon, Feb 22 2010, Benjamin S. wrote: > > On Sun, 21 Feb 2010 16:00:35 -0600 > Robert Hancock <hancockrwd@xxxxxxxxx> wrote: > > > Hmm.. Well, that's not it then.. I suspect a bisection is likely the > > easiest route at this point.. > > fb1e75389bd06fd5987e9cda1b4e0305c782f854 is the first bad commit > commit fb1e75389bd06fd5987e9cda1b4e0305c782f854 > Author: Jens Axboe <jens.axboe@xxxxxxxxxx> > Date: Thu Jul 30 08:18:24 2009 +0200 > > block: improve queue_should_plug() by looking at IO depths > > Instead of just checking whether this device uses block layer > tagging, we can improve the detection by looking at the maximum > queue depth it has reached. If that crosses 4, then deem it a > queuing device. > > This is important on high IOPS devices, since plugging hurts > the performance there (it can be as much as 10-15% of the sys > time). > > Signed-off-by: Jens Axboe <jens.axboe@xxxxxxxxxx> > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fb1e75389bd06fd5987e9cda1b4e0305c782f854 > > > Without that patch my SSD (Super Talent Ultradrive GX MLC 64GB) > reaches about 200MB/s sequentiell read. After applying the patch it > reaches only 70MB/s. That's not good. Can you send me the dmesg snippet that includes the drive detection? -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
