All of lore.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 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.