[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: Andi Kleen <ak@xxxxxxx>
Date: Tue, 4 Oct 2005 17:59:14 +0200
Cc: Eric Sandeen <sandeen@xxxxxxx>, linux-xfs@xxxxxxxxxxx, axboe@xxxxxxx
In-reply-to: <4342A2AB.4040700@xfs.org>
References: <BAY110-F272BEC2E5C429160FB4068B4830@phx.gbl> <p73u0fxz4xa.fsf@verdi.suse.de> <4342A2AB.4040700@xfs.org>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: KMail/1.8.2
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.

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.


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