All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <righiandr@users.sourceforge.net>
To: Bill Davidsen <davidsen@tmr.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [RFC][PATCH] per-task I/O throttling
Date: Fri, 11 Jan 2008 11:28:39 +0100 (MET)	[thread overview]
Message-ID: <478744D7.2070802@users.sourceforge.net> (raw)
In-Reply-To: <4786CB57.9060000@tmr.com>

Bill Davidsen wrote:
> 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.

At the moment I'm simply using it to backup my PC by this wrapper:

$ cat iothrottle
#!/bin/sh
[ $# -lt 2 ] && echo "usage: $0 RATE CMD" && exit 1
rate=$1
shift
$* &
trap "kill -9 $!" SIGINT SIGTERM
[ -e /proc/$!/io_throttle ] && echo $rate >/proc/$!/io_throttle
wait %1
$ ./iothrottle 100 tar ...

But I totally agree with you that setting the limits per-UID/per-GID,
instead of per-task, would be actually more useful.

Maybe a nice approach would be to define the UID/GID upper bounds via
configfs (for example) and allow the users to tune the max I/O rate of
their single tasks according to the defined ranges. In this way it could
be even possible to define I/O shaping policies, i.e. give a bandwidth
of 10MB/s to user A, 20MB/s to user B, 30MB/s to group X, etc.

Anyway, I'm wondering if it's possible (and how) to already do this with
process containers...

-Andrea

  reply	other threads:[~2008-01-11 10:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-10 22:45 [RFC][PATCH] per-task I/O throttling Andrea Righi
2008-01-11  1:50 ` Bill Davidsen
2008-01-11 10:28   ` Andrea Righi [this message]
2008-01-11 14:20     ` Peter Zijlstra
2008-01-11 15:29       ` Andrea Righi
2008-01-11 14:05 ` David Newall
2008-01-11 15:44   ` Andrea Righi
2008-01-16 19:21     ` David Newall
2008-01-11 15:59 ` Balbir Singh
2008-01-11 16:32   ` Andrea Righi
2008-01-12  4:57     ` Valdis.Kletnieks
2008-01-12  9:46       ` Peter Zijlstra
2008-01-12 10:57         ` Balbir Singh
2008-01-12 11:10           ` Peter Zijlstra
2008-01-12 18:01             ` Andrea Righi
2008-01-13  4:46               ` Balbir Singh
2008-01-15 16:49                 ` [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling) Andrea Righi
2008-01-11 17:58                   ` Pavel Machek
2008-01-23 15:41                     ` Andrea Righi
2008-01-16 10:45                   ` Balbir Singh
2008-01-16 11:30                     ` Valdis.Kletnieks
2008-01-16 12:05                       ` Balbir Singh
2008-01-16 12:24                         ` Valdis.Kletnieks
2008-01-16 12:58                     ` Andrea Righi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=478744D7.2070802@users.sourceforge.net \
    --to=righiandr@users.sourceforge.net \
    --cc=davidsen@tmr.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.