From: Michael Tokarev <mjt@tls.msk.ru>
To: Jan Kara <jack@suse.cz>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: dramatic I/O slowdown after upgrading 2.6.32->3.0
Date: Fri, 06 Apr 2012 08:45:40 +0400 [thread overview]
Message-ID: <4F7E74F4.90604@msgid.tls.msk.ru> (raw)
In-Reply-To: <20120405232913.GA6640@quack.suse.cz>
On 06.04.2012 03:29, Jan Kara wrote:
> On Fri 30-03-12 20:50:54, Michael Tokarev wrote:
>> I'm observing a dramatic slowdown of several hosts after upgrading
>> from 2.6.32.y to 3.0.x i686 kernels (in both cases from kernel.org,
>> on both cases the last version is relatively latest).
[]
>> What's the way to debug this issue?
> Identifying a particular kernel where things regresses might help as Jon
> wrote. Just from top of my head, 3.0 had a bug in device plugging so
> readahead was broken. I think it was addressed in -stable series so you
That's definitely not readahead, it since writes are painfully slow
too. I found one more example -- extlinux --once="test kernel" with
3.0 takes about 20 seconds to complete on an idle system.
> might want to check out latest 3.0-stable.
I did mention this in my initial email (that part quoted above) --
both 2.6.32 and 3.0 are relatively latest from each series,
right now it is 3.0.27.
Yesterday I tried to do some bisection, but ended up in an unbootable
system (it is remote production server), so now I'm waiting for remote
hands to repair it (I don't yet know what went wrong, we'll figure it
out). I've some time during nights when I can do anything with that
machine, but I have to keep it reachable/working on each reboot.
Apparently I was wrong saying that there's another machine which
suffers from the same issue -- nope, the other machine had an unrelated
issue which I fixed. So it turns out that from about 200 different
machines, I've just one machine which does not run 3.0 kernel properly.
I especially tried 3.0 on a few more - different - machines last
weekend, in order to see what other machines has this problem, but
found nothing.
So I'll try to continue (or actually _start_) the bisection on this
very server, the way it will be possible having in mind the difficult
conditions.
I just thoght I'd ask first, maybe someone knows offhand what may be
the problem.. ;)
Thank you!
/mjt
next prev parent reply other threads:[~2012-04-06 4:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-30 16:50 dramatic I/O slowdown after upgrading 2.6.32->3.0 Michael Tokarev
2012-04-02 16:58 ` Jonathan Corbet
2012-04-05 23:29 ` Jan Kara
2012-04-06 4:45 ` Michael Tokarev [this message]
2012-04-10 2:26 ` Dave Chinner
2012-04-10 6:00 ` dramatic I/O slowdown after upgrading 2.6.38->3.0+ Michael Tokarev
2012-04-10 15:13 ` Jan Kara
2012-04-10 19:25 ` Suresh Jayaraman
2012-04-10 19:51 ` Jan Kara
2012-04-11 0:20 ` Henrique de Moraes Holschuh
2012-04-11 9:40 ` Michael Tokarev
2012-04-11 17:19 ` Mike Christie
2012-04-11 17:55 ` Michael Tokarev
2012-04-11 18:28 ` Jan Kara
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=4F7E74F4.90604@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.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.