On Tue, Oct 17 2006, Arjan van de Ven wrote:
> On Mon, 2006-10-16 at 16:46 -0400, Phetteplace, Thad (GE Healthcare,
> consultant) wrote:
> > The I/O priority levels available under the CFQ scheduler are
> > nice (no pun in intended), but I remember some talk back when
> > they first went in that future versions might include bandwidth
> > allocations in addition to the 'niceness' style. Is anyone out
> > there working on that? If not, I'm willing to hack up a proof
> > of concept... I just wan't to make sure I'm not reinventing
> > the wheel.
>
>
> Hi,
>
> it's a nice idea in theory. However... since IO bandwidth for seeks is
> about 1% to 3% of that of sequential IO (on disks at least), which
> bandwidth do you want to allocate? "worst case" you need to use the
> all-seeks bandwidth, but that's so far away from "best case" that it may
> well not be relevant in practice. Yet there are real world cases where
> for a period of time you approach worst case behavior ;(
Bandwidth reservation would have to be confined to special cases, you
obviously cannot do it "in general" for the reasons Arjan lists above.
So you absolutely have to limit any meta data io that would cause seeks,
and the file in question would have to be laid out in a closely
sequential fashion. As long as the access pattern generated by the app
asking for reservation is largely sequential, the kernel can do whatever
it needs to help you maintain the required bandwidth.
On a per-file basis the bandwidth reservation should be doable, to the
extent that generic hardware allows.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
