mirror of https://lore.kernel.org/lkml/
 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: 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
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
     [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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome