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]

Date:	Thu, 10 Jan 2008 20:50:15 -0500
From:	Bill Davidsen <davidsen@....com>
To:	righiandr@...rs.sourceforge.net
CC:	LKML <linux-kernel@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [RFC][PATCH] per-task I/O throttling

Andrea Righi wrote:
> Allow to limit the bandwidth of I/O-intensive processes, like backup
> tools running in background, large files copy, checksums on huge files,
> etc.
> 
> This kind of processes can noticeably impact the system responsiveness
> for some time and playing with tasks' priority is not always an
> acceptable solution.
> 
> This patch allows to specify a maximum I/O rate in sectors per second
> for each single process via /proc/<PID>/io_throttle (default is zero,
> that specify no limit).
> 
It would seem to me that this would be vastly more useful in the real 
world if there were a settable default, so that administrators could 
avoid having to find and tune individual user processes. And it would 
seem far less common that the admin would want to set the limit *up* for 
a given process, and it's likely to be one known to the admin, at least 
by name.

Of course if you want to do the effort to make it fully tunable, it 
could have a default by UID or GID. Usful on machines shared by students 
or managers.

-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
--
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/