Andi Kleen wrote:
On Tuesday 04 October 2005 17:41, Steve Lord wrote:
Andi Kleen wrote:
Eric Sandeen <sandeen@xxxxxxx> writes:
That is basically true, yes. There is a non-free GRIOV2 product in
use with CXFS, but for your purposes, I think it is safe to say that
there is no standalone GRIO equivalent on Linux.
It's not. In fact it's a standard feature now.
The CFQ2 IO scheduler has IO priorities settable with ionice, including
a RT class with 8 priorities.
It's not available in SLES9 though, only in newer kernels (2.6.13+)
and SUSE releases (like SL10.0)
-Andi
Ah, but is there a bandwidth reservation system to go with it? That is
the missing link here, being able to say 'I need 10 Mbytes/sec until
further notice'.
Indirectly there is. The RT priority defines how many time slots you
get and the length of the timeslots are configurable using sysfs. If you know
the bandwidth of the disk you can use that to define an approximation
of the guaranteed bandwidth for a specific RT priority.
On the other hand I don't really see how you can get real bandwidths.
e.g. on most disks the bandwidth varies greatly depending on where
the blocks are allocated and how much seeking it does. If you take
that all in account you'll probably get a pretty slow worst case
as baseline to divide.
If you get into this stuff seriously you have to dedicate hardware
all the way from the cpu to the disks, make worst case estimates of how
fast your disks will go. Multiply all this out and say that to record n
streams of HD video without dropping a frame you need this much hardware.
It is a bit of a black magic art, and not something you just go out and
buy a PC to do. It tends to waste a lot of the potential bandwidth of
the hardware, but you try explaining to CNN why their satellite feed just
went black ;-)
Steve
There is nothing that actually gives out bandwidths, but you could
do that in user space.
Jens may correct me if I'm wrong on anything.
-Andi
|