[Top] [All Lists]

Re: The XFS real-time subvolume in Linux

To: Steve Lord <lord@xxxxxxx>
Subject: Re: The XFS real-time subvolume in Linux
From: Jens Axboe <axboe@xxxxxxx>
Date: Wed, 5 Oct 2005 10:41:18 +0200
Cc: Andi Kleen <ak@xxxxxxx>, Eric Sandeen <sandeen@xxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <4342AAD3.8060102@xxxxxxx>
References: <BAY110-F272BEC2E5C429160FB4068B4830@xxxxxxx> <p73u0fxz4xa.fsf@xxxxxxxxxxxxx> <4342A2AB.4040700@xxxxxxx> <200510041759.15075.ak@xxxxxxx> <4342AAD3.8060102@xxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
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)
> >>>
> >>>-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 ;-)

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..

Jens Axboe

<Prev in Thread] Current Thread [Next in Thread>