Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: [Bug 12309] Large I/O operations result in slow performance and high iowait times

369 views
Skip to first unread message

Thomas Pilarski

unread,
Mar 30, 2010, 3:50:02 AM3/30/10
to
Sorry for the late answer.

There is regression in desktop responsiveness from 2.6.32 to 2.6.33. I
am working on a notebook with a full encrypted lvm partition. The
throughput of the disk is about 70MB/s in the outer regions. There is
another hard disk in an ultra bay slot.

While 2.6.32 is "usable", the 2.6.33 freezes for up to two minutes in a
30 seconds interval while tracker starts to index a new inserted hard
disk with a lot of small files (openembedded build tree). This starts
with a wrong configured tracker and the 2.6.32 kernel with freezes up to
10 seconds.

The indexed ultrabay dics is not encrypted and formated with ext4, only
the indexes are writen on an ext3 partition in an ecrypted logical
volume group, which also contains the system partition.

This problem is enormous increased, while the ultra bay disc is acceded
with udma2 instead of udma6 (caused by another bug),

I can execute some tests, but you should tell me, which results you need
to identify the problem.

Thomas Pilarski


Am Dienstag, den 16.03.2010, 23:57 +0000 schrieb
bugzill...@bugzilla.kernel.org:
> http://bugzilla.kernel.org/show_bug.cgi?id=12309
>
> --- Comment #420 from Andrew Morton <ak...@linux-foundation.org> 2010-03-16 23:56:58 ---
> (In reply to comment #419)
> > I am currently using the linux kernel 2.6.33 and the the desktop responsiveness
> > is awful on my machine compared to the 2.6.32.x kernel. It's even worse than I
> > have even seen it before. The load avg is rising to >7 very quickly, while
> > writing many small file to the filesystem. I can make some tests with my
> > configuration, but a kernel developer should tell me which tests.
>
> This isn't really the best place to bring this up. Please send a full
> description to linux-...@vger.kernel.org. cc myself, Ingo Molnar
> <mi...@elte.hu>, Peter Zijlstra <a.p.zi...@chello.nl>, Jens Axboe
> <jens....@oracle.com>. In that email, please identify what the system is
> doing at the time. Is it disk-related? CPU scheduler related? etc.
>
> Thanks.
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Henrique de Moraes Holschuh

unread,
Mar 30, 2010, 8:30:03 PM3/30/10
to
On Tue, 30 Mar 2010, Thomas Pilarski wrote:
> This problem is enormous increased, while the ultra bay disc is acceded
> with udma2 instead of udma6 (caused by another bug),

There is a thinkpad BIOS bug that could cause that: it will not signal a
80-wire cable when you hot-add an HD on a PATA ultrabay. Exists at least on
all T4x, including the T43.

The fix is to whitelist these thinkpads for high-speed UDMA even on 40-wire
cables. The workaround is to add a kernel command line parameter (I forget
which).

Does that match your udma2 instead of udma6 problem?

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

Thomas Pilarski

unread,
Apr 3, 2010, 3:30:02 PM4/3/10
to
> > This problem is enormous increased, while the ultra bay disc is acceded
> > with udma2 instead of udma6 (caused by another bug),
>
> There is a thinkpad BIOS bug that could cause that: it will not signal a
> 80-wire cable when you hot-add an HD on a PATA ultrabay. Exists at least on
> all T4x, including the T43.

It's a SATA untrabay disk. There is a 40-wire message, but sometimes it
works and sometimes not. I could not figure out, when it does and when
not.

> The fix is to whitelist these thinkpads for high-speed UDMA even on 40-wire
> cables. The workaround is to add a kernel command line parameter (I forget
> which).
>
> Does that match your udma2 instead of udma6 problem?

Thanks. I will try it. But have to finish another project first.

Henrique de Moraes Holschuh

unread,
Apr 3, 2010, 10:10:01 PM4/3/10
to
On Sat, 03 Apr 2010, Thomas Pilarski wrote:
> > > This problem is enormous increased, while the ultra bay disc is acceded
> > > with udma2 instead of udma6 (caused by another bug),
> >
> > There is a thinkpad BIOS bug that could cause that: it will not signal a
> > 80-wire cable when you hot-add an HD on a PATA ultrabay. Exists at least on
> > all T4x, including the T43.
>
> It's a SATA untrabay disk. There is a 40-wire message, but sometimes it
> works and sometimes not. I could not figure out, when it does and when
> not.

Which ThinkPad model? And yes, if it is the BIOS 40-wire problem, it
doesn't show up always. I keep forgetting exactly how to trigger it (I
think it is hotplug device when you boot with the bay empty), but it is
100% reproducible.

> > The fix is to whitelist these thinkpads for high-speed UDMA even on 40-wire
> > cables. The workaround is to add a kernel command line parameter (I forget
> > which).
> >
> > Does that match your udma2 instead of udma6 problem?
>
> Thanks. I will try it. But have to finish another project first.

Just make sure to tell me if the ata 40-wire short cable override fixes
your problem when you get around to trying it.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

0 new messages