Messages in this thread | | | Subject | Re: Prioritized I/O | Date | Sun, 15 Aug 1999 08:51:54 +0200 (MEST) | From | (Rogier Wolff) |
| |
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/
| |