public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: Lee Revell <rlrevell@joe-job.com>
Cc: Christian <christiand59@web.de>, linux-kernel@vger.kernel.org
Subject: Re: Sluggish system responsiveness on I/O
Date: Sun, 19 Nov 2006 19:34:55 +0100	[thread overview]
Message-ID: <1163961295.5977.53.camel@Homer.simpson.net> (raw)
In-Reply-To: <1163958288.22176.82.camel@mindpipe>

On Sun, 2006-11-19 at 12:44 -0500, Lee Revell wrote:
> On Sun, 2006-11-19 at 08:51 +0100, Mike Galbraith wrote:
> > That makes sense, I/O tasks don't generally hold the cpu for extended
> > periods, whereas a cpu bound task does.
> 
> So what can we do about I/O intensive tasks that also want a lot of CPU,
> for example, the bloatier Gnome/KDE apps?  Evolution is the worst for
> me.


Evolution has big trouble with the ext3 (and maybe others) journal.
I've _never_ seen evolution having scheduler priority problems, only
journal problems (absolutely every damn time hefty I/O is going on).

What should we do about I/O tasks that decide to use massive cpu?

IMHO, absolutely nothing beyond what ever we decide to do with any other
cpu intensvive task.  There is nothing special about scheduling I/O
heavy tasks.  If it uses massive cpu for sustained periods, it must pay
the price.  In the meantime, an I/O intensive task that decides to use
heavy cpu will round-robin at relatively high frequency with every other
"interactive" task, which may also be doing a burst of cpu heavy work.
The reason for doing that cpu intensive burst just doesn't matter.

Currently, we special case I/O tasks to limit the dynamic priority boost
they can get via I/O.  I think that is wrong.

	-Mike


  reply	other threads:[~2006-11-19 18:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-18 13:12 Sluggish system responsiveness on I/O Christian
2006-11-18 13:25 ` Prakash Punnoor
2006-11-18 14:40   ` Christian
2006-11-19  7:51 ` Mike Galbraith
2006-11-19 17:44   ` Lee Revell
2006-11-19 18:34     ` Mike Galbraith [this message]
2006-11-22 10:57       ` [rfc patch] " Mike Galbraith

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=1163961295.5977.53.camel@Homer.simpson.net \
    --to=efault@gmx.de \
    --cc=christiand59@web.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rlrevell@joe-job.com \
    /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