All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Takashi Ikebe <ikebe.takashi@lab.ntt.co.jp>
Cc: andrea@suse.de, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Real-time problem due to IO congestion.
Date: Fri, 10 Jun 2005 08:24:53 +0200	[thread overview]
Message-ID: <20050610062452.GK5140@suse.de> (raw)
In-Reply-To: <42A91D36.8090506@lab.ntt.co.jp>

On Fri, Jun 10 2005, Takashi Ikebe wrote:
> Hello,
> I have been encountering big real-time problem due to IO congestion, and
> I want some advices.
> 
> -The problem description-
> There are 2 type processes in test environment.
> 1. The real-time needed process (run on with high static priority)
>     The process wake up every 10ms, and wake up, write some log (the
> test case is current CPU clock via tsc) to the file.
> 
> 2. The process which make IO load
>     The process have large memory size, and kill the process with dumping.
>     The process's memory area exceeds 70% of whole physical
> RAM.(Actually 1.5GB memory area while whole RAM is 2GB)
> 
> Whenever during dumping, the real-time needed process sometimes stop for
> long time during write system call. (sometimes exceeds 1000ms)
> I tested every IO scheduler but the same problem occurs.
> I also seek this problem into the code, and find that the stops are
> mainly occurring on blk_congestion_wait/get_request/get_request_wait
> functions located on drivers/block/ll_rw_blk.c.
> 
> -My assumption-
> The design of IO(read/write) queue and queuing is not well match to
> real-time needed processes.
> If there are many IO requests by low priority processes already, then
> the IO request by high priority process should wait until queue goes
> clean, and this cause some kind of priority inversions.
> 
> -My suggestion-
> Add the new IO scheduler or change current IO scheduler to reflect
> process's priority on queuing.
> 
> I don't know my assumption and suggestion are correct and you like,
> would you give me some advices?

This basically needs io priorities to work, so that request allocation
is prioritized as well. I didn't actually add request allocation groups
in the cfq-ts posted with priority support, however I have some patches
from years ago that did so. I'll see if I can find the time to brush
those off.

-- 
Jens Axboe


  reply	other threads:[~2005-06-10  6:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-10  4:55 Real-time problem due to IO congestion Takashi Ikebe
2005-06-10  6:24 ` Jens Axboe [this message]
2005-06-10  7:49   ` Takashi Ikebe
2005-06-10 18:26     ` Lee Revell
2005-06-10  6:42 ` Andrew Morton
2005-06-10  7:13   ` Takashi Ikebe
2005-06-10  7:21     ` Jens Axboe
2005-06-10 20:25     ` Helge Hafting
2005-06-13  1:46       ` Takashi Ikebe

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=20050610062452.GK5140@suse.de \
    --to=axboe@suse.de \
    --cc=andrea@suse.de \
    --cc=ikebe.takashi@lab.ntt.co.jp \
    --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 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.