linux-kernel - Re: Bandwidth Allocations under CFQ I/O Scheduler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061017132312.GD7854@kernel.dk>
Date:	Tue, 17 Oct 2006 15:23:13 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	"Phetteplace, Thad (GE Healthcare, consultant)" 
	<Thad.Phetteplace@...com>, linux-kernel@...r.kernel.org
Subject: Re: Bandwidth Allocations under CFQ I/O Scheduler

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/