Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-23 Thread Andrea Righi
Pavel Machek wrote:
> On Tue 2008-01-15 17:49:36, Andrea Righi wrote:
>> Allow to limit the I/O bandwidth for specific uid(s) or gid(s) imposing
>> additional delays on those processes that exceed the limits defined in a
>> configfs tree.
>>
>> Examples:
>>
>> Limit the I/O bandwidth for user www-data (UID 33) to 4MB/s:
>>
>> [EMAIL PROTECTED]:/config/io-throttle# mkdir uid:33
>> [EMAIL PROTECTED]:/config/io-throttle# cd uid:33/
>> [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
>>  io-rate: 0 KiB/sec
>>requested: 0 KiB
>> last_request: 0 jiffies
>>delta: 388202 jiffies
>> [EMAIL PROTECTED]:/config/io-throttle/uid:33# echo 4096 > io-rate
>> [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
>>  io-rate: 4096 KiB/sec
>>requested: 0 KiB
>> last_request: 389271 jiffies
>>delta: 91 jiffies
>>
>> Limit the I/O bandwidth of group backup (GID 34) to 512KB/s:
> 
> Maybe ionice from cfq should be improved, instead?

IMHO it would be interesting to have also a way to use the limiting
approach, instead of i/o priority-based only (i.e. checks to ensure that
servicing the requests will not cause the associated user's maximum
quality of service to be exceeded).

see also http://lkml.org/lkml/2008/1/20/157

-Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-23 Thread Pavel Machek
On Tue 2008-01-15 17:49:36, Andrea Righi wrote:
> Allow to limit the I/O bandwidth for specific uid(s) or gid(s) imposing
> additional delays on those processes that exceed the limits defined in a
> configfs tree.
> 
> Examples:
> 
> Limit the I/O bandwidth for user www-data (UID 33) to 4MB/s:
> 
> [EMAIL PROTECTED]:/config/io-throttle# mkdir uid:33
> [EMAIL PROTECTED]:/config/io-throttle# cd uid:33/
> [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
>  io-rate: 0 KiB/sec
>requested: 0 KiB
> last_request: 0 jiffies
>delta: 388202 jiffies
> [EMAIL PROTECTED]:/config/io-throttle/uid:33# echo 4096 > io-rate
> [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
>  io-rate: 4096 KiB/sec
>requested: 0 KiB
> last_request: 389271 jiffies
>delta: 91 jiffies
> 
> Limit the I/O bandwidth of group backup (GID 34) to 512KB/s:

Maybe ionice from cfq should be improved, instead?
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-23 Thread Pavel Machek
On Tue 2008-01-15 17:49:36, Andrea Righi wrote:
 Allow to limit the I/O bandwidth for specific uid(s) or gid(s) imposing
 additional delays on those processes that exceed the limits defined in a
 configfs tree.
 
 Examples:
 
 Limit the I/O bandwidth for user www-data (UID 33) to 4MB/s:
 
 [EMAIL PROTECTED]:/config/io-throttle# mkdir uid:33
 [EMAIL PROTECTED]:/config/io-throttle# cd uid:33/
 [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
  io-rate: 0 KiB/sec
requested: 0 KiB
 last_request: 0 jiffies
delta: 388202 jiffies
 [EMAIL PROTECTED]:/config/io-throttle/uid:33# echo 4096  io-rate
 [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
  io-rate: 4096 KiB/sec
requested: 0 KiB
 last_request: 389271 jiffies
delta: 91 jiffies
 
 Limit the I/O bandwidth of group backup (GID 34) to 512KB/s:

Maybe ionice from cfq should be improved, instead?
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-23 Thread Andrea Righi
Pavel Machek wrote:
 On Tue 2008-01-15 17:49:36, Andrea Righi wrote:
 Allow to limit the I/O bandwidth for specific uid(s) or gid(s) imposing
 additional delays on those processes that exceed the limits defined in a
 configfs tree.

 Examples:

 Limit the I/O bandwidth for user www-data (UID 33) to 4MB/s:

 [EMAIL PROTECTED]:/config/io-throttle# mkdir uid:33
 [EMAIL PROTECTED]:/config/io-throttle# cd uid:33/
 [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
  io-rate: 0 KiB/sec
requested: 0 KiB
 last_request: 0 jiffies
delta: 388202 jiffies
 [EMAIL PROTECTED]:/config/io-throttle/uid:33# echo 4096  io-rate
 [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
  io-rate: 4096 KiB/sec
requested: 0 KiB
 last_request: 389271 jiffies
delta: 91 jiffies

 Limit the I/O bandwidth of group backup (GID 34) to 512KB/s:
 
 Maybe ionice from cfq should be improved, instead?

IMHO it would be interesting to have also a way to use the limiting
approach, instead of i/o priority-based only (i.e. checks to ensure that
servicing the requests will not cause the associated user's maximum
quality of service to be exceeded).

see also http://lkml.org/lkml/2008/1/20/157

-Andrea
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-16 Thread Andrea Righi
Balbir Singh wrote:
> * Andrea Righi <[EMAIL PROTECTED]> [2008-01-15 17:49:36]:
> 
>> Allow to limit the I/O bandwidth for specific uid(s) or gid(s) imposing
>> additional delays on those processes that exceed the limits defined in a
>> configfs tree.
>>
>> Examples:
>>
>> Limit the I/O bandwidth for user www-data (UID 33) to 4MB/s:
>>
>> [EMAIL PROTECTED]:/config/io-throttle# mkdir uid:33
>> [EMAIL PROTECTED]:/config/io-throttle# cd uid:33/
>> [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
>>  io-rate: 0 KiB/sec
>>requested: 0 KiB
>> last_request: 0 jiffies
>>delta: 388202 jiffies
>> [EMAIL PROTECTED]:/config/io-throttle/uid:33# echo 4096 > io-rate
>> [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
>>  io-rate: 4096 KiB/sec
>>requested: 0 KiB
>> last_request: 389271 jiffies
>>delta: 91 jiffies
>>
>> Limit the I/O bandwidth of group backup (GID 34) to 512KB/s:
>>
>> [EMAIL PROTECTED]:/config/io-throttle# mkdir gid:34
>> [EMAIL PROTECTED]:/config/io-throttle# cd gid:34/
>> [EMAIL PROTECTED]:/config/io-throttle/gid:34# cat io-rate
>>  io-rate: 0 KiB/sec
>>requested: 0 KiB
>> last_request: 0 jiffies
>>delta: 403160 jiffies
>> [EMAIL PROTECTED]:/config/io-throttle/gid:34# echo 512 > io-rate
>> [EMAIL PROTECTED]:/config/io-throttle/gid:34# cat io-rate
>>  io-rate: 512 KiB/sec
>>requested: 0 KiB
>> last_request: 403618 jiffies
>>delta: 80 jiffies
>>
>> Remove the I/O limit for user www-data:
>>
>> [EMAIL PROTECTED]:/config/io-throttle# echo 0 > uid:33/io-rate
>> [EMAIL PROTECTED]:/config/io-throttle# cat uid:33/io-rate
>>  io-rate: 0 KiB/sec
>>requested: 0 KiB
>> last_request: 419009 jiffies
>>delta: 568 jiffies
>>
>> or:
>>
>> [EMAIL PROTECTED]:/config/io-throttle# rmdir uid:33
>>
>> Future improvements:
>> * allow to limit also I/O operations per second (instead of KB/s only)
>> * extend grouping criteria (allow to define rules based on process 
>> containers,
>>   process command, etc.) 
>>
>> Signed-off-by: Andrea Righi <[EMAIL PROTECTED]>
> 
> Hi, Andrea,
> 
> Thanks for doing this. I am going to review the patches in greater
> detail and also test them. Why do you use configfs when we have a
> control group filesystem available for grouping tasks and providing a
> file system based interface for control and accounting?
> 

Well... I didn't choose configfs for a technical reason, but simply
because I'm more familiar with it, respect to the other equivalent ways
to implement this. But I'll try to look also at the control group
approach, I don't know in details all the advantages/disadvantages, but
it seems interesting anyway.

-Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-16 Thread Valdis . Kletnieks
On Wed, 16 Jan 2008 17:35:33 +0530, Balbir Singh said:

> Control groups is derived from cpusets and for those interested in
> grouping tasks for control, is the preferred method of providing
> control.

Ahh, that's why I didn't notice it - "cpusets" didn't seem to do much for the 1
and 2 CPU systems I usually deal with so I filtered it out (including the parts
where it started becoming relevant to things I do).  Often, the right tool for
a job is something you've never heard of because it originated in some other
specialized area...



pgpYZ8o1u5Ht4.pgp
Description: PGP signature


Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-16 Thread Balbir Singh
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-01-16 06:30:31]:

> On Wed, 16 Jan 2008 16:15:41 +0530, Balbir Singh said:
> 
> > Thanks for doing this. I am going to review the patches in greater
> > detail and also test them. Why do you use configfs when we have a
> > control group filesystem available for grouping tasks and providing a
> > file system based interface for control and accounting?
> 
> And here I thought "There's more than one way to do it" was the Perl slogan. 
> :)
>

Yes, there are several ways to do it, but the discussion over the last
year or so has been centered around control groups. We've discussed
all approaches on lkml on there was consensus on using control groups.
Please read the lkml archives for the discussion details.

 
> An equally valid question would be: "Why are we carrying around a control
> group filesystem when we have configfs?"  (Honestly, I didn't know we *were*
> carrying around such a filesystem - and quite likely Andrea Righi didn't
> either...)

Control groups is derived from cpusets and for those interested in
grouping tasks for control, is the preferred method of providing
control.


-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-16 Thread Valdis . Kletnieks
On Wed, 16 Jan 2008 16:15:41 +0530, Balbir Singh said:

> Thanks for doing this. I am going to review the patches in greater
> detail and also test them. Why do you use configfs when we have a
> control group filesystem available for grouping tasks and providing a
> file system based interface for control and accounting?

And here I thought "There's more than one way to do it" was the Perl slogan. :)

An equally valid question would be: "Why are we carrying around a control
group filesystem when we have configfs?"  (Honestly, I didn't know we *were*
carrying around such a filesystem - and quite likely Andrea Righi didn't
either...)


pgpeGKJYihyer.pgp
Description: PGP signature


Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-16 Thread Balbir Singh
* Andrea Righi <[EMAIL PROTECTED]> [2008-01-15 17:49:36]:

> Allow to limit the I/O bandwidth for specific uid(s) or gid(s) imposing
> additional delays on those processes that exceed the limits defined in a
> configfs tree.
> 
> Examples:
> 
> Limit the I/O bandwidth for user www-data (UID 33) to 4MB/s:
> 
> [EMAIL PROTECTED]:/config/io-throttle# mkdir uid:33
> [EMAIL PROTECTED]:/config/io-throttle# cd uid:33/
> [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
>  io-rate: 0 KiB/sec
>requested: 0 KiB
> last_request: 0 jiffies
>delta: 388202 jiffies
> [EMAIL PROTECTED]:/config/io-throttle/uid:33# echo 4096 > io-rate
> [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
>  io-rate: 4096 KiB/sec
>requested: 0 KiB
> last_request: 389271 jiffies
>delta: 91 jiffies
> 
> Limit the I/O bandwidth of group backup (GID 34) to 512KB/s:
> 
> [EMAIL PROTECTED]:/config/io-throttle# mkdir gid:34
> [EMAIL PROTECTED]:/config/io-throttle# cd gid:34/
> [EMAIL PROTECTED]:/config/io-throttle/gid:34# cat io-rate
>  io-rate: 0 KiB/sec
>requested: 0 KiB
> last_request: 0 jiffies
>delta: 403160 jiffies
> [EMAIL PROTECTED]:/config/io-throttle/gid:34# echo 512 > io-rate
> [EMAIL PROTECTED]:/config/io-throttle/gid:34# cat io-rate
>  io-rate: 512 KiB/sec
>requested: 0 KiB
> last_request: 403618 jiffies
>delta: 80 jiffies
> 
> Remove the I/O limit for user www-data:
> 
> [EMAIL PROTECTED]:/config/io-throttle# echo 0 > uid:33/io-rate
> [EMAIL PROTECTED]:/config/io-throttle# cat uid:33/io-rate
>  io-rate: 0 KiB/sec
>requested: 0 KiB
> last_request: 419009 jiffies
>delta: 568 jiffies
> 
> or:
> 
> [EMAIL PROTECTED]:/config/io-throttle# rmdir uid:33
> 
> Future improvements:
> * allow to limit also I/O operations per second (instead of KB/s only)
> * extend grouping criteria (allow to define rules based on process containers,
>   process command, etc.) 
> 
> Signed-off-by: Andrea Righi <[EMAIL PROTECTED]>

Hi, Andrea,

Thanks for doing this. I am going to review the patches in greater
detail and also test them. Why do you use configfs when we have a
control group filesystem available for grouping tasks and providing a
file system based interface for control and accounting?

-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-16 Thread Valdis . Kletnieks
On Wed, 16 Jan 2008 16:15:41 +0530, Balbir Singh said:

 Thanks for doing this. I am going to review the patches in greater
 detail and also test them. Why do you use configfs when we have a
 control group filesystem available for grouping tasks and providing a
 file system based interface for control and accounting?

And here I thought There's more than one way to do it was the Perl slogan. :)

An equally valid question would be: Why are we carrying around a control
group filesystem when we have configfs?  (Honestly, I didn't know we *were*
carrying around such a filesystem - and quite likely Andrea Righi didn't
either...)


pgpeGKJYihyer.pgp
Description: PGP signature


Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-16 Thread Balbir Singh
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2008-01-16 06:30:31]:

 On Wed, 16 Jan 2008 16:15:41 +0530, Balbir Singh said:
 
  Thanks for doing this. I am going to review the patches in greater
  detail and also test them. Why do you use configfs when we have a
  control group filesystem available for grouping tasks and providing a
  file system based interface for control and accounting?
 
 And here I thought There's more than one way to do it was the Perl slogan. 
 :)


Yes, there are several ways to do it, but the discussion over the last
year or so has been centered around control groups. We've discussed
all approaches on lkml on there was consensus on using control groups.
Please read the lkml archives for the discussion details.

 
 An equally valid question would be: Why are we carrying around a control
 group filesystem when we have configfs?  (Honestly, I didn't know we *were*
 carrying around such a filesystem - and quite likely Andrea Righi didn't
 either...)

Control groups is derived from cpusets and for those interested in
grouping tasks for control, is the preferred method of providing
control.


-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-16 Thread Valdis . Kletnieks
On Wed, 16 Jan 2008 17:35:33 +0530, Balbir Singh said:

 Control groups is derived from cpusets and for those interested in
 grouping tasks for control, is the preferred method of providing
 control.

Ahh, that's why I didn't notice it - cpusets didn't seem to do much for the 1
and 2 CPU systems I usually deal with so I filtered it out (including the parts
where it started becoming relevant to things I do).  Often, the right tool for
a job is something you've never heard of because it originated in some other
specialized area...



pgpYZ8o1u5Ht4.pgp
Description: PGP signature


Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-16 Thread Andrea Righi
Balbir Singh wrote:
 * Andrea Righi [EMAIL PROTECTED] [2008-01-15 17:49:36]:
 
 Allow to limit the I/O bandwidth for specific uid(s) or gid(s) imposing
 additional delays on those processes that exceed the limits defined in a
 configfs tree.

 Examples:

 Limit the I/O bandwidth for user www-data (UID 33) to 4MB/s:

 [EMAIL PROTECTED]:/config/io-throttle# mkdir uid:33
 [EMAIL PROTECTED]:/config/io-throttle# cd uid:33/
 [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
  io-rate: 0 KiB/sec
requested: 0 KiB
 last_request: 0 jiffies
delta: 388202 jiffies
 [EMAIL PROTECTED]:/config/io-throttle/uid:33# echo 4096  io-rate
 [EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
  io-rate: 4096 KiB/sec
requested: 0 KiB
 last_request: 389271 jiffies
delta: 91 jiffies

 Limit the I/O bandwidth of group backup (GID 34) to 512KB/s:

 [EMAIL PROTECTED]:/config/io-throttle# mkdir gid:34
 [EMAIL PROTECTED]:/config/io-throttle# cd gid:34/
 [EMAIL PROTECTED]:/config/io-throttle/gid:34# cat io-rate
  io-rate: 0 KiB/sec
requested: 0 KiB
 last_request: 0 jiffies
delta: 403160 jiffies
 [EMAIL PROTECTED]:/config/io-throttle/gid:34# echo 512  io-rate
 [EMAIL PROTECTED]:/config/io-throttle/gid:34# cat io-rate
  io-rate: 512 KiB/sec
requested: 0 KiB
 last_request: 403618 jiffies
delta: 80 jiffies

 Remove the I/O limit for user www-data:

 [EMAIL PROTECTED]:/config/io-throttle# echo 0  uid:33/io-rate
 [EMAIL PROTECTED]:/config/io-throttle# cat uid:33/io-rate
  io-rate: 0 KiB/sec
requested: 0 KiB
 last_request: 419009 jiffies
delta: 568 jiffies

 or:

 [EMAIL PROTECTED]:/config/io-throttle# rmdir uid:33

 Future improvements:
 * allow to limit also I/O operations per second (instead of KB/s only)
 * extend grouping criteria (allow to define rules based on process 
 containers,
   process command, etc.) 

 Signed-off-by: Andrea Righi [EMAIL PROTECTED]
 
 Hi, Andrea,
 
 Thanks for doing this. I am going to review the patches in greater
 detail and also test them. Why do you use configfs when we have a
 control group filesystem available for grouping tasks and providing a
 file system based interface for control and accounting?
 

Well... I didn't choose configfs for a technical reason, but simply
because I'm more familiar with it, respect to the other equivalent ways
to implement this. But I'll try to look also at the control group
approach, I don't know in details all the advantages/disadvantages, but
it seems interesting anyway.

-Andrea
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-15 Thread Andrea Righi
Allow to limit the I/O bandwidth for specific uid(s) or gid(s) imposing
additional delays on those processes that exceed the limits defined in a
configfs tree.

Examples:

Limit the I/O bandwidth for user www-data (UID 33) to 4MB/s:

[EMAIL PROTECTED]:/config/io-throttle# mkdir uid:33
[EMAIL PROTECTED]:/config/io-throttle# cd uid:33/
[EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
 io-rate: 0 KiB/sec
   requested: 0 KiB
last_request: 0 jiffies
   delta: 388202 jiffies
[EMAIL PROTECTED]:/config/io-throttle/uid:33# echo 4096 > io-rate
[EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
 io-rate: 4096 KiB/sec
   requested: 0 KiB
last_request: 389271 jiffies
   delta: 91 jiffies

Limit the I/O bandwidth of group backup (GID 34) to 512KB/s:

[EMAIL PROTECTED]:/config/io-throttle# mkdir gid:34
[EMAIL PROTECTED]:/config/io-throttle# cd gid:34/
[EMAIL PROTECTED]:/config/io-throttle/gid:34# cat io-rate
 io-rate: 0 KiB/sec
   requested: 0 KiB
last_request: 0 jiffies
   delta: 403160 jiffies
[EMAIL PROTECTED]:/config/io-throttle/gid:34# echo 512 > io-rate
[EMAIL PROTECTED]:/config/io-throttle/gid:34# cat io-rate
 io-rate: 512 KiB/sec
   requested: 0 KiB
last_request: 403618 jiffies
   delta: 80 jiffies

Remove the I/O limit for user www-data:

[EMAIL PROTECTED]:/config/io-throttle# echo 0 > uid:33/io-rate
[EMAIL PROTECTED]:/config/io-throttle# cat uid:33/io-rate
 io-rate: 0 KiB/sec
   requested: 0 KiB
last_request: 419009 jiffies
   delta: 568 jiffies

or:

[EMAIL PROTECTED]:/config/io-throttle# rmdir uid:33

Future improvements:
* allow to limit also I/O operations per second (instead of KB/s only)
* extend grouping criteria (allow to define rules based on process containers,
  process command, etc.) 

Signed-off-by: Andrea Righi <[EMAIL PROTECTED]>
---

diff -urpN linux-2.6.24-rc7/block/io-throttle.c 
linux-2.6.24-rc7-io-throttle/block/io-throttle.c
--- linux-2.6.24-rc7/block/io-throttle.c1970-01-01 01:00:00.0 
+0100
+++ linux-2.6.24-rc7-io-throttle/block/io-throttle.c2008-01-15 
17:25:06.0 +0100
@@ -0,0 +1,282 @@
+/*
+ * io-throttle.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ *
+ * Copyright (C) 2008 Andrea Righi <[EMAIL PROTECTED]>
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* This should work for any reasonable size of uid_t */
+#define MAXUIDCHAR (sizeof(uid_t) * 5 / 2)
+
+/*
+ * Basic structure that identifies a single I/O throttling rule
+ */
+struct iothrottle {
+   struct config_item item;
+   unsigned long iorate;
+   unsigned long req;
+   unsigned long last_request;
+};
+
+/* Get an I/O-throttling item from a configfs item */
+static inline struct iothrottle *to_iothrottle(struct config_item *item)
+{
+   return item ? container_of(item, struct iothrottle, item) : NULL;
+}
+
+static ssize_t iothrottle_attr_show(struct config_item *item,
+   struct configfs_attribute *attr,
+   char *page);
+static ssize_t iothrottle_attr_store(struct config_item *item,
+struct configfs_attribute *attr,
+const char *page, size_t count);
+static struct config_item *iothrottle_make_item(struct config_group *group,
+   const char *name);
+static void iothrottle_release(struct config_item *item);
+
+/* I/O throttling item in configfs (identify a single I/O throttling rule) */
+static struct configfs_attribute iothrottle_attr_iorate = {
+   .ca_owner = THIS_MODULE,
+   .ca_name = "io-rate",
+   .ca_mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH,
+};
+
+/* I/O throttling element in configfs */
+static struct configfs_group_operations iothrottle_group_ops = {
+   .make_item  = iothrottle_make_item,
+};
+
+static struct config_item_type iothrottle_group_type = {
+   .ct_group_ops   = _group_ops,
+};
+
+/* Entire I/O throttling subsystem under configfs (/config/io-throttle) */
+struct configfs_subsystem iothrottle_subsys = {
+   .su_group = {
+   .cg_item = {
+   .ci_namebuf = "io-throttle",
+   .ci_type = _group_type,
+   },
+   },

[RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)

2008-01-15 Thread Andrea Righi
Allow to limit the I/O bandwidth for specific uid(s) or gid(s) imposing
additional delays on those processes that exceed the limits defined in a
configfs tree.

Examples:

Limit the I/O bandwidth for user www-data (UID 33) to 4MB/s:

[EMAIL PROTECTED]:/config/io-throttle# mkdir uid:33
[EMAIL PROTECTED]:/config/io-throttle# cd uid:33/
[EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
 io-rate: 0 KiB/sec
   requested: 0 KiB
last_request: 0 jiffies
   delta: 388202 jiffies
[EMAIL PROTECTED]:/config/io-throttle/uid:33# echo 4096  io-rate
[EMAIL PROTECTED]:/config/io-throttle/uid:33# cat io-rate
 io-rate: 4096 KiB/sec
   requested: 0 KiB
last_request: 389271 jiffies
   delta: 91 jiffies

Limit the I/O bandwidth of group backup (GID 34) to 512KB/s:

[EMAIL PROTECTED]:/config/io-throttle# mkdir gid:34
[EMAIL PROTECTED]:/config/io-throttle# cd gid:34/
[EMAIL PROTECTED]:/config/io-throttle/gid:34# cat io-rate
 io-rate: 0 KiB/sec
   requested: 0 KiB
last_request: 0 jiffies
   delta: 403160 jiffies
[EMAIL PROTECTED]:/config/io-throttle/gid:34# echo 512  io-rate
[EMAIL PROTECTED]:/config/io-throttle/gid:34# cat io-rate
 io-rate: 512 KiB/sec
   requested: 0 KiB
last_request: 403618 jiffies
   delta: 80 jiffies

Remove the I/O limit for user www-data:

[EMAIL PROTECTED]:/config/io-throttle# echo 0  uid:33/io-rate
[EMAIL PROTECTED]:/config/io-throttle# cat uid:33/io-rate
 io-rate: 0 KiB/sec
   requested: 0 KiB
last_request: 419009 jiffies
   delta: 568 jiffies

or:

[EMAIL PROTECTED]:/config/io-throttle# rmdir uid:33

Future improvements:
* allow to limit also I/O operations per second (instead of KB/s only)
* extend grouping criteria (allow to define rules based on process containers,
  process command, etc.) 

Signed-off-by: Andrea Righi [EMAIL PROTECTED]
---

diff -urpN linux-2.6.24-rc7/block/io-throttle.c 
linux-2.6.24-rc7-io-throttle/block/io-throttle.c
--- linux-2.6.24-rc7/block/io-throttle.c1970-01-01 01:00:00.0 
+0100
+++ linux-2.6.24-rc7-io-throttle/block/io-throttle.c2008-01-15 
17:25:06.0 +0100
@@ -0,0 +1,282 @@
+/*
+ * io-throttle.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ *
+ * Copyright (C) 2008 Andrea Righi [EMAIL PROTECTED]
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/configfs.h
+#include linux/slab.h
+#include linux/sched.h
+#include linux/jiffies.h
+#include linux/io-throttle.h
+
+/* This should work for any reasonable size of uid_t */
+#define MAXUIDCHAR (sizeof(uid_t) * 5 / 2)
+
+/*
+ * Basic structure that identifies a single I/O throttling rule
+ */
+struct iothrottle {
+   struct config_item item;
+   unsigned long iorate;
+   unsigned long req;
+   unsigned long last_request;
+};
+
+/* Get an I/O-throttling item from a configfs item */
+static inline struct iothrottle *to_iothrottle(struct config_item *item)
+{
+   return item ? container_of(item, struct iothrottle, item) : NULL;
+}
+
+static ssize_t iothrottle_attr_show(struct config_item *item,
+   struct configfs_attribute *attr,
+   char *page);
+static ssize_t iothrottle_attr_store(struct config_item *item,
+struct configfs_attribute *attr,
+const char *page, size_t count);
+static struct config_item *iothrottle_make_item(struct config_group *group,
+   const char *name);
+static void iothrottle_release(struct config_item *item);
+
+/* I/O throttling item in configfs (identify a single I/O throttling rule) */
+static struct configfs_attribute iothrottle_attr_iorate = {
+   .ca_owner = THIS_MODULE,
+   .ca_name = io-rate,
+   .ca_mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH,
+};
+
+/* I/O throttling element in configfs */
+static struct configfs_group_operations iothrottle_group_ops = {
+   .make_item  = iothrottle_make_item,
+};
+
+static struct config_item_type iothrottle_group_type = {
+   .ct_group_ops   = iothrottle_group_ops,
+};
+
+/* Entire I/O throttling subsystem under configfs (/config/io-throttle) */
+struct configfs_subsystem iothrottle_subsys = {
+   .su_group = {
+   .cg_item = {
+