All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: Erik Mouw <erik@harddisk-recovery.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
	"Martin J. Bligh" <mbligh@mbligh.org>,
	Andrew Morton <akpm@osdl.org>,
	Jason Schoonover <jasons@pioneer-pra.com>,
	linux-kernel@vger.kernel.org
Subject: Re: High load average on disk I/O on 2.6.17-rc3
Date: Mon, 08 May 2006 19:18:03 +0200	[thread overview]
Message-ID: <1147108683.8026.52.camel@homer> (raw)
In-Reply-To: <20060508154217.GH1875@harddisk-recovery.com>

On Mon, 2006-05-08 at 17:42 +0200, Erik Mouw wrote:
> On Mon, May 08, 2006 at 05:31:29PM +0200, Arjan van de Ven wrote:
> > On Mon, 2006-05-08 at 17:22 +0200, Erik Mouw wrote:
> > > ... except that any kernel < 2.6 didn't account tasks waiting for disk
> > > IO.
> > 
> > they did. It was "D" state, which counted into load average.
> 
> They did not or at least to a much lesser extent. That's the reason why
> ZenIV.linux.org.uk had a mail DoS during the last FC release and why we
> see load average questions on lkml.

I distinctly recall it counting, but since I don't have a 2.4 tree
handy, I'll refrain from saying "did _too_" ;-)

> I've seen it on our servers as well: when using 2.4 and doing 50 MB/s
> to disk (through NFS), the load just was slightly above 0. When we
> switched the servers to 2.6 it went to ~16 for the same disk usage.

The main difference I see is...

8129 root      15   0  3500  512  432 D 56.0  0.0   0:33.72 bonnie
 1393 root      10  -5     0    0    0 D  0.4  0.0   0:00.26 kjournald
 8135 root      15   0     0    0    0 D  0.0  0.0   0:00.01 pdflush
  573 root      15   0     0    0    0 D  0.0  0.0   0:00.00 pdflush
  574 root      15   0     0    0    0 D  0.0  0.0   0:00.04 pdflush
 8131 root      15   0     0    0    0 D  0.0  0.0   0:00.01 pdflush
 8141 root      15   0     0    0    0 D  0.0  0.0   0:00.00 pdflush

With 2.4, there was only one flush thread.  Same load, different
loadavg... in this particular case of one user task running.  IIRC, if
you had a bunch of things running and running you low on memory, you
could end up with a slew of 'D' state tasks in 2.4 as well, because
allocating tasks had to help free memory by flushing buffers and pushing
swap.  Six to one, half a dozen to the other.

	-Mike


  parent reply	other threads:[~2006-05-08 17:17 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05 17:10 High load average on disk I/O on 2.6.17-rc3 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
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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2006-05-05 17:58 Jason Schoonover
     [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=1147108683.8026.52.camel@homer \
    --to=efault@gmx.de \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=erik@harddisk-recovery.com \
    --cc=jasons@pioneer-pra.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@mbligh.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.