On Tue, Oct 04 2005, Steve Lord wrote:
> 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)
> >>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 ;-)
That's exactly why the Linux ioprio stuff has been designed the way it
is right now - it's not overengineered for something we cannot support
anyways. The CFQ io priorities will work well enough for general use, if
you are basing your business on GRIO it's a different game completely. I
don't want to add kernel infrastructure for something that is very
specialized, especially because the code to do so would be 10 times
bigger and more complex that the current stuff..