lkml.org 
[lkml]   [1999]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Prioritized I/O
Date
From

Larry McVoy wrote:
> Steven Suson writes:
> > I've been thinking about the discussions on latency, especially in
> > regards to multilmedia recording, etc. If I/O were prioritized in the
> > way that CPU utilization is, then this would allow R/T processes to also
> > take precendence for I/O, thus reducing latency. In addition, this
> > yields all sorts of benefits for time sensitive I/O.

[snip]

> It never went in because there are fairness issues - consider a system
> generating a lot of dirty pages and you are giving reads higher priority.
> The system grinds to a halt. I never solved that part of the problem.

Another problem is that it doesn't give you any real-time guarantees.

Suppose I have one program linearly reading a disk at low
priority. And one RT process (Higher priority task, whatever) that
wants to do some IO. It will always find the disk busy with one of the
requests from that other process. The time to service that IO will
always be a seek plus average rotational latency plus transfertime.

Suppose they both want to read the disk linearly. They will do a "fair
share" of the disk: while the highprio process does its IO the low
priority process always has a chance to get it's IO requests
queued. So the disk will ping-pong between the two different locations
and max out around 60 - 100 IOs per second. Multiply that by the
readahead that you grant them, and you have the throughput. Something
like 1.5Mb per second max. (On a disk capable of 10 times more).

SGI have solved this problem in the part of XFS that they are not
freeing.

The problem is that the high-prio process always finds an IO request
scheduled on the disk. It can go ahead of the queue and be the next
one to get serviced, but it cannot abort the command already on the
disk.

If the high-prio process wants an IO rate of 7.5Mb per second, (half
the disk bandwidth), we need to guarantee it finding the disk idle
50% of the time.

To achieve this, you should dedicate all "even" jiffies to the
high-prio process. During the "odd" jiffies, it has to time-share with
the lower-priority process. So if the low-prio process comes in and
wants a disk block during an even jiffie, you just tell it to
wait. Even when the disk is idle at that time.

Then this mechanism can have some refinements: If the high-prio
process does't do any IOs during a shared-IO slot, the shared-IO slot
can be extended. Of course, if the real-time (high-prio, multimedia,
whatever) process puts in a request for 5Mb per second on your 15Mbper
second disk, you only need to dedicate a third of the slots to the
high-priority process. If it requests 14.85Mb per second, the rest of
the system can only use 1% of the slots.

Larry, to solve the problem that you brought up, how about
artificially increasing the priority of the write requests with the
urgency that we need the memory. Would that work?


Roger.

--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------


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

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.042 / U:2.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site