Messages in this thread | | | Date | Sun, 15 Aug 1999 17:26:04 +0200 | From | David Olofson <> | Subject | Re: Prioritized I/O |
| |
Rogier Wolff wrote: (...Latency...) > Another problem is that it doesn't give you any real-time guarantees.
I think this discussion seems to be straying a bit from the definitions of "real time"... I hope we're not dealing with _hard_ real time AND low latency!?
Well, as long as "low latency" is not in the same order of magnitude as the disk seek times, it's possible (even if not a simple hack), but I still think it's the wrong way to do it. Ok, starting to read from anywhere in a huge file within 20 ms would be nice, but I doubt it's possible to do reliably without at least locking the entire drive to the task. And now we're just dealing with _one_ file. I need to access 10-50 files in parallel...
I'd split the problem i two parts; 1) start access time, and 2) guaranteed transfer rate.
The distinction won't help much if you really need 1) all the time, but in most applications, you need 1) only when starting to _read_, and then 2) for the actual (buffered) streaming.
For 1) there are all the problems with disk access time and other requests being processed when you need to get in, but for 2), "all" you need is guaranteed average transfer rate within a specified time frame. Priority is needed for both, but for 2), it doesn't have to be very fine grained WRT timing, which simplifies things a lot. (It still has to go into the code somewhere in between the file system and the disk, but there should be no need to cancel requests in progress, unless they take very long.)
I understand the need for low latency in applications where you can't cache any explicit start points in files, but what are the requirements here? Do you really need _hard_ real time guarantees, or would lowest possible latency, followed by guaranteed transfer rate do?
(...multiple tasks...) > 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.
Ok, what are the possibilities here? Basically, the access time of a hard disk is a physical limitation, and the only way around it is preloading and buffering. Don't ask me about the details of implementing that in a general purpose file system, but the basic rule is "It's still rotating disks and moving heads."
> 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.
Hmm... You'd make a good attempt on frying the seek motor that way. Using sufficient buffering while streaming, it's reduced to a matter of scheduling requests WRT priority, size and physical location on the disk.
I'd go for optimized throughput, with the addition of "x bytes from file y MUST be in memory before time z", and then look at ways to break in and yell "Hey! I need to start reading file a at pos b ASAP!". For a high prio task, that would mean that all other task are blocked from the disk for a moment, until the high prio task have enough read-ahead buffers to guarantee the requested transfer rate.
> 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?
What about doing the same thing as all recording systems with swapping to disk should do: Use a separate drive for recording. Or just don't use any swap. You can't have it all at the same time... unless you can stand that extra disk, that is. ;-)
Hope that makes some sense... :-)
//David
- 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/
| |