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
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:
>
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
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)
Andrea Righi wrote:
> David Newall wrote:
>
>> Andrea Righi wrote:
>>
>>> [I/O-intensive] processes can noticeably impact the system responsiveness
>>> for some time and playing with tasks' priority is not always an
>>> acceptable solution.
>>>
>>>
>> Why?
>>
>>
>
> Well, I
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
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
* [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
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
* 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
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
* [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
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
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
Andrea Righi wrote:
David Newall wrote:
Andrea Righi wrote:
[I/O-intensive] processes can noticeably impact the system responsiveness
for some time and playing with tasks' priority is not always an
acceptable solution.
Why?
Well, I mean, we can't use 'nice' to
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
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
* Andrea Righi <[EMAIL PROTECTED]> [2008-01-12 19:01:14]:
> Peter Zijlstra wrote:
> > On Sat, 2008-01-12 at 16:27 +0530, Balbir Singh wrote:
> >> * Peter Zijlstra <[EMAIL PROTECTED]> [2008-01-12 10:46:37]:
> >>
> >>> On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote:
> On Fri, 11
Peter Zijlstra wrote:
> On Sat, 2008-01-12 at 16:27 +0530, Balbir Singh wrote:
>> * Peter Zijlstra <[EMAIL PROTECTED]> [2008-01-12 10:46:37]:
>>
>>> On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote:
On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said:
> The interesting
On Sat, 2008-01-12 at 16:27 +0530, Balbir Singh wrote:
> * Peter Zijlstra <[EMAIL PROTECTED]> [2008-01-12 10:46:37]:
>
> >
> > On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote:
> > > On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said:
> > >
> > > > The interesting feature is that
* Peter Zijlstra <[EMAIL PROTECTED]> [2008-01-12 10:46:37]:
>
> On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote:
> > On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said:
> >
> > > The interesting feature is that it allows to set a priority for each
> > > process container, but
On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote:
> On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said:
>
> > The interesting feature is that it allows to set a priority for each
> > process container, but AFAIK it doesn't allow to "partition" the
> > bandwidth between different
On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote:
On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said:
The interesting feature is that it allows to set a priority for each
process container, but AFAIK it doesn't allow to partition the
bandwidth between different containers
* Peter Zijlstra [EMAIL PROTECTED] [2008-01-12 10:46:37]:
On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote:
On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said:
The interesting feature is that it allows to set a priority for each
process container, but AFAIK it doesn't
On Sat, 2008-01-12 at 16:27 +0530, Balbir Singh wrote:
* Peter Zijlstra [EMAIL PROTECTED] [2008-01-12 10:46:37]:
On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote:
On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said:
The interesting feature is that it allows to set a
Peter Zijlstra wrote:
On Sat, 2008-01-12 at 16:27 +0530, Balbir Singh wrote:
* Peter Zijlstra [EMAIL PROTECTED] [2008-01-12 10:46:37]:
On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote:
On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said:
The interesting feature is that it allows
* Andrea Righi [EMAIL PROTECTED] [2008-01-12 19:01:14]:
Peter Zijlstra wrote:
On Sat, 2008-01-12 at 16:27 +0530, Balbir Singh wrote:
* Peter Zijlstra [EMAIL PROTECTED] [2008-01-12 10:46:37]:
On Fri, 2008-01-11 at 23:57 -0500, [EMAIL PROTECTED] wrote:
On Fri, 11 Jan 2008 17:32:49 +0100,
On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said:
> The interesting feature is that it allows to set a priority for each
> process container, but AFAIK it doesn't allow to "partition" the
> bandwidth between different containers (that would be a nice feature
> IMHO). For example it would be
Balbir Singh wrote:
> On Jan 11, 2008 4:15 AM, Andrea Righi <[EMAIL PROTECTED]> 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
On Jan 11, 2008 4:15 AM, Andrea Righi <[EMAIL PROTECTED]> 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
David Newall wrote:
> Andrea Righi wrote:
>> [I/O-intensive] processes can noticeably impact the system responsiveness
>> for some time and playing with tasks' priority is not always an
>> acceptable solution.
>>
>
> Why?
>
Well, I mean, we can't use 'nice' to grant less priority for the I/O
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
On Fri, 2008-01-11 at 11:28 +0100, Andrea Righi wrote:
> 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
Andrea Righi wrote:
[I/O-intensive] processes can noticeably impact the system responsiveness
for some time and playing with tasks' priority is not always an
acceptable solution.
Why?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
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
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
On Fri, 2008-01-11 at 11:28 +0100, Andrea Righi wrote:
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
David Newall wrote:
Andrea Righi wrote:
[I/O-intensive] processes can noticeably impact the system responsiveness
for some time and playing with tasks' priority is not always an
acceptable solution.
Why?
Well, I mean, we can't use 'nice' to grant less priority for the I/O
intensive
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
On Jan 11, 2008 4:15 AM, Andrea Righi [EMAIL PROTECTED] 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
Balbir Singh wrote:
On Jan 11, 2008 4:15 AM, Andrea Righi [EMAIL PROTECTED] 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
Andrea Righi wrote:
[I/O-intensive] processes can noticeably impact the system responsiveness
for some time and playing with tasks' priority is not always an
acceptable solution.
Why?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Fri, 11 Jan 2008 17:32:49 +0100, Andrea Righi said:
The interesting feature is that it allows to set a priority for each
process container, but AFAIK it doesn't allow to partition the
bandwidth between different containers (that would be a nice feature
IMHO). For example it would be great
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
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
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
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
47 matches
Mail list logo
