linux-kernel - Re: [RFC][PATCH] per-task I/O throttling

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: <47878B68.5070806@users.sourceforge.net>
Date:	Fri, 11 Jan 2008 16:29:44 +0100 (MET)
From:	Andrea Righi <righiandr@...rs.sourceforge.net>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Bill Davidsen <davidsen@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [RFC][PATCH] per-task I/O throttling

Peter Zijlstra wrote:
>>
>> Anyway, I'm wondering if it's possible (and how) to already do this with
>> process containers...
> 
> I think there is an IO controller somewhere based on CFQ.
> 
> I don't like this patch, because it throttles requests/s, and that
> doesn't say much. If a task would generate a very seeky load it could
> still tie up the disk even with a relatively low setting.
> 

Very true. A seeky intensive process wouldn't be limited at all. And I'm
sure there're better ways/models to satisfy my needs.

A suggestion (off-list) has been to try with ionice that seems to be the
right solution to limit the I/O activity of single processes, but it
doens't allow to define policies based on UIDs or GIDs.

BTW I don't have any number to compare the effectiveness of the priority
approach vs the throttling approach. Here is a very quick test made on
my PC (not sure if glxgears is the right benchmark to evaluate
the system responsiveness):

>>>>>> starting: glxgears <<<<<<
3564 frames in 5.0 seconds = 711.722 FPS
3953 frames in 5.0 seconds = 790.598 FPS
3969 frames in 5.0 seconds = 793.794 FPS
>>>>>> starting: md5sum /usr/lib/* <<<<<<
3769 frames in 5.0 seconds = 753.189 FPS
2877 frames in 5.0 seconds = 572.843 FPS
3481 frames in 5.0 seconds = 696.071 FPS
3775 frames in 5.0 seconds = 751.404 FPS
2781 frames in 5.0 seconds = 556.118 FPS
3209 frames in 5.0 seconds = 641.064 FPS
2843 frames in 5.0 seconds = 565.697 FPS
>>>>>> starting: echo 100 > /proc/`pidof md5sum`/io_throttle <<<<<<
3652 frames in 5.0 seconds = 730.253 FPS
3669 frames in 5.0 seconds = 733.734 FPS
3797 frames in 5.0 seconds = 759.234 FPS
3883 frames in 5.0 seconds = 776.488 FPS
3895 frames in 5.0 seconds = 778.868 FPS
3845 frames in 5.0 seconds = 768.968 FPS
3829 frames in 5.0 seconds = 765.793 FPS

>>>>>> flush caches (/proc/sys/vm/drop_caches) <<<<<<

>>>>>> starting: glxgears <<<<<<
3763 frames in 5.0 seconds = 752.539 FPS
3818 frames in 5.0 seconds = 763.483 FPS
>>>>>> starting: ionice -c3 md5sum /usr/lib/* <<<<<<
3443 frames in 5.0 seconds = 688.597 FPS
3202 frames in 5.0 seconds = 640.390 FPS
3807 frames in 5.0 seconds = 761.391 FPS
3053 frames in 5.0 seconds = 610.539 FPS
2759 frames in 5.0 seconds = 551.790 FPS
2975 frames in 5.0 seconds = 594.873 FPS
2993 frames in 5.0 seconds = 596.709 FPS
3250 frames in 5.0 seconds = 649.857 FPS
3494 frames in 5.0 seconds = 698.688 FPS

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