xfs
[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>