Re: [RFC][PATCH] per-uid/gid I/O throttling (was Re: [RFC][PATCH] per-task I/O throttling)
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)
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)
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)
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)
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)
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)
* [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)
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)
* 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)
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)
* [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)
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)
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/
