mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jason Schoonover <jasons@pioneer-pra.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: High load average on disk I/O on 2.6.17-rc3
Date: Sun, 7 May 2006 10:24:22 -0700	[thread overview]
Message-ID: <200605071024.22341.jasons@pioneer-pra.com> (raw)
In-Reply-To: <20060507095039.089ad37c.akpm@osdl.org>

Hi Andrew,

I see, so it sounds as though the load average is not telling the true load of 
the machine.  However, it still feels that it's consuming quite a bit of 
resources.  The machine is almost unresponsive if I were to start two or 
three copies at the same time.

I noticed the behavior initially when I installed vmware server: I started one 
of the vm's booting and was copying another in the background (about a 12GB 
directory).  The booting VM would started getting slower and slower and 
eventually just hung.  It wasn't locked up, just seemed like it was "paused."   
When I tried an "ls" in another window, it just hung.  I then tried to ssh 
into the server to open another window and I couldn't even get an ssh prompt.  
I had to eventually Ctrl-C the copy and wait for it to be done before I could 
do anything.  And the load average had skyrocketed, but the consensus here is 
definitely that it's not the true load average of the system.

Possibly should I revert back to an older kernel?  2.6.12 or 2.6.10 maybe?  Do 
you know when abouts the I/O was changed?

I can certainly help debug this issue if you (or someone else) has the time to 
look into it and fix it.  Otherwise I will just revert back and hope that it 
will get fixed in the future.

Thanks,
Jason


-------Original Message-----
From: Andrew Morton
Sent: Sunday 07 May 2006 09:50
To: Jason Schoonover
Subject: Re: High load average on disk I/O on 2.6.17-rc3

On Fri, 5 May 2006 10:10:19 -0700

Jason Schoonover <jasons@pioneer-pra.com> wrote:
> I'm having some problems on the latest 2.6.17-rc3 kernel and SCSI disk I/O.
> Whenever I copy any large file (over 500GB) the load average starts to
> slowly rise and after about a minute it is up to 7.5 and keeps on rising
> (depending on how long the file takes to copy).  When I watch top, the
> processes at the top of the list are cp, pdflush, kjournald and kswapd.

This is probably because the number of pdflush threads slowly grows to its
maximum.  This is bogus, and we seem to have broken it sometime in the past
few releases.  I need to find a few quality hours to get in there and fix
it, but they're rare :(

It's pretty harmless though.  The "load average" thing just means that the
extra pdflush threads are twiddling thumbs waiting on some disk I/O -
they'll later exit and clean themselves up.  They won't be consuming
significant resources.

  reply	other threads:[~2006-05-07 17:25 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05 17:10 Jason Schoonover
2006-05-06 23:03 ` bert hubert
2006-05-07  1:02   ` Jason Schoonover
2006-05-07 10:54     ` bert hubert
2006-05-07 16:50 ` Andrew Morton
2006-05-07 17:24   ` Jason Schoonover [this message]
2006-05-08 11:13   ` Erik Mouw
2006-05-08 11:22     ` Arjan van de Ven
2006-05-08 11:28       ` Russell King
2006-05-08 11:38         ` Avi Kivity
2006-05-08 12:37         ` Arjan van de Ven
2006-05-09 14:37         ` Bill Davidsen
2006-05-08 14:24   ` Martin J. Bligh
2006-05-08 14:55     ` Arjan van de Ven
2006-05-08 15:22       ` Erik Mouw
2006-05-08 15:25         ` Martin J. Bligh
2006-05-08 15:31         ` Arjan van de Ven
2006-05-08 15:42           ` Erik Mouw
2006-05-08 16:02             ` Martin J. Bligh
2006-05-08 16:02             ` Miquel van Smoorenburg
2006-05-08 16:47             ` Russell King
2006-05-08 17:04               ` Gabor Gombas
2006-05-08 17:18             ` Mike Galbraith
2006-05-09  1:57           ` Nick Piggin
2006-05-09  2:02             ` Martin Bligh
2006-05-09  2:16               ` Nick Piggin
2006-05-09  4:36             ` Arjan van de Ven
2006-05-09  4:46               ` Nick Piggin
2006-05-09  5:27                 ` Hua Zhong
2006-05-09  5:03               ` David Lang
2006-05-15  7:46                 ` Sander
2006-05-08 22:24         ` Bernd Eckenfels
2006-05-08 22:39           ` Lee Revell
2006-05-09  0:08           ` Peter Williams
2006-05-09 18:33           ` Bill Davidsen
     [not found] <69c8K-3Bu-57@gated-at.bofh.it>
2006-05-05 23:12 ` Robert Hancock
2006-05-06  4:39   ` Jason Schoonover
2006-05-06 17:20     ` Robert Hancock
2006-05-06 18:23       ` Jason Schoonover
2006-05-06 20:01         ` Robert Hancock

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=200605071024.22341.jasons@pioneer-pra.com \
    --to=jasons@pioneer-pra.com \
    --cc=akpm@osdl.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®