linux-kernel - Re: [PATCH] cgroup: limit block I/O bandwidth

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: <20080120160651.GU6258@kernel.dk>
Date:	Sun, 20 Jan 2008 17:06:51 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Andrea Righi <righiandr@...rs.sourceforge.net>
Cc:	Naveen Gupta <ngupta@...gle.com>, Paul Menage <menage@...gle.com>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cgroup: limit block I/O bandwidth

On Sun, Jan 20 2008, Andrea Righi wrote:
> Jens Axboe wrote:
> > Your approach is totally flawed, imho. For instance, you don't want a
> > process to be able to dirty memory at foo mb/sec but only actually
> > write them out at bar mb/sec.
> 
> Right. Actually my problem here is that the processes that write out
> blocks are different respect to the processes that write bytes in
> memory, and I would be able to add limits on those processes that are
> dirtying memory.

That's another reason why you cannot do this on a per-process or group
basis, because you have no way of mapping back from the io queue path
which process originally dirtied this memory.

> > The noop-iosched changes are also very buggy. The queue back pointer
> > breaks reference counting and the task pointer storage assumes the task
> > will also always be around. That's of course not the case.
> 
> Yes, this really need a lot of fixes. I simply posted the patch to know
> if such approach (in general) could have sense or not.

It doesn't need fixes, it needs to be redesigned :-). No amount of
fixing will make the patch you posted correct, since the approach is
simply not feasible.

> > IOW, you are doing this at the wrong level.
> > 
> > What problem are you trying to solve?
> 
> Limiting block I/O bandwidth for tasks that belong to a generic cgroup,
> in order to provide a sort of a QoS on block I/O.
> 
> Anyway, I'm quite new in the wonderful land of the I/O scheduling, so
> any help is appreciated.

For starters, you want to throttle when queuing IO, not dispatching it.
If you need to modify IO schedulers, then you are already at the wrong
level. That doesn't solve the write problem, but reads can be done.

If you want to solve for both read/write(2), then move the code to that
level. That wont work for eg mmap, though...

And as Balbir notes, the openvz group have been looking at some of these
problems as well. As has lots of other people btw, you probably want to
search around a bit and acquaint yourself with some of that work.

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