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/