Re: Real-time problem due to IO congestion.

[Jens Axboe <axboe@suse.de>]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/