* Andrea Righi <[EMAIL PROTECTED]> [2008-01-24 14:48:01]:
> Pavel Emelyanov wrote:
> > Andrea Righi wrote:
> >> Balbir Singh wrote:
> >>> * Andrea Righi <[EMAIL PROTECTED]> [2008-01-23 16:23:59]:
> >>>
> Probably tracking who dirtied the pages would be the best approach, but
> we want al
Pavel Emelyanov wrote:
> Andrea Righi wrote:
>> Balbir Singh wrote:
>>> * Andrea Righi <[EMAIL PROTECTED]> [2008-01-23 16:23:59]:
>>>
Probably tracking who dirtied the pages would be the best approach, but
we want also to reduce the overhead of this tracking. So, we should find
a sma
Andrea Righi wrote:
> Balbir Singh wrote:
>> * Andrea Righi <[EMAIL PROTECTED]> [2008-01-23 16:23:59]:
>>
>>> Probably tracking who dirtied the pages would be the best approach, but
>>> we want also to reduce the overhead of this tracking. So, we should find
>>> a smart way to track which cgroup di
Balbir Singh wrote:
> * Andrea Righi <[EMAIL PROTECTED]> [2008-01-23 16:23:59]:
>
>> Probably tracking who dirtied the pages would be the best approach, but
>> we want also to reduce the overhead of this tracking. So, we should find
>> a smart way to track which cgroup dirtied the pages and then o
* Andrea Righi <[EMAIL PROTECTED]> [2008-01-23 16:23:59]:
> Probably tracking who dirtied the pages would be the best approach, but
> we want also to reduce the overhead of this tracking. So, we should find
> a smart way to track which cgroup dirtied the pages and then only when
> the i/o schedule
Naveen Gupta wrote:
> On 22/01/2008, Andrea Righi <[EMAIL PROTECTED]> wrote:
>> Naveen Gupta wrote:
>>> See if using priority levels to have per level bandwidth limit can
>>> solve the priority inversion problem you were seeing earlier. I have a
>>> priority scheduling patch for anticipatory schedu
On 22/01/2008, Andrea Righi <[EMAIL PROTECTED]> wrote:
> Naveen Gupta wrote:
> > See if using priority levels to have per level bandwidth limit can
> > solve the priority inversion problem you were seeing earlier. I have a
> > priority scheduling patch for anticipatory scheduler, if you want to
> >
Naveen Gupta wrote:
> See if using priority levels to have per level bandwidth limit can
> solve the priority inversion problem you were seeing earlier. I have a
> priority scheduling patch for anticipatory scheduler, if you want to
> try it. It's much simpler than CFQ priority. I still need to po
On 20/01/2008, Andrea Righi <[EMAIL PROTECTED]> wrote:
> Jens Axboe wrote:
> > On Sun, Jan 20 2008, Andrea Righi wrote:
> >> Jens Axboe wrote:
> >>> Your approach is totally flawed, imho. For instance, you don't want a
> >>> process to be able to dirty memory at foo mb/sec but only actually
> >>> w
Jens Axboe wrote:
> On Sun, Jan 20 2008, Andrea Righi wrote:
>> Jens Axboe wrote:
>>> Your approach is totally flawed, imho. For instance, you don't want a
>>> process to be able to dirty memory at foo mb/sec but only actually
>>> write them out at bar mb/sec.
>> Right. Actually my problem here is
On Sun, Jan 20 2008, Andrea Righi wrote:
> Jens Axboe wrote:
> > Your approach is totally flawed, imho. For instance, you don't want a
> > process to be able to dirty memory at foo mb/sec but only actually
> > write them out at bar mb/sec.
>
> Right. Actually my problem here is that the processes
Jens Axboe wrote:
> Your approach is totally flawed, imho. For instance, you don't want a
> process to be able to dirty memory at foo mb/sec but only actually
> write them out at bar mb/sec.
Right. Actually my problem here is that the processes that write out
blocks are different respect to the pr
* Jens Axboe <[EMAIL PROTECTED]> [2008-01-20 15:32:40]:
> On Sun, Jan 20 2008, Andrea Righi wrote:
> Your approach is totally flawed, imho. For instance, you don't want a
> process to be able to dirty memory at foo mb/sec but only actually
> write them out at bar mb/sec.
>
> The noop-iosched chan
On Sun, Jan 20 2008, Andrea Righi wrote:
> Andrea Righi wrote:
> > Naveen Gupta wrote:
> >>> Paul Menage wrote:
> On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
> > On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
> >> Allow to limit the block I/O ban
Andrea Righi wrote:
> Naveen Gupta wrote:
>>> Paul Menage wrote:
On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
>> Allow to limit the block I/O bandwidth for specific process containers
>> (cgrou
Naveen Gupta wrote:
>> Paul Menage wrote:
>>> On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
> Allow to limit the block I/O bandwidth for specific process containers
> (cgroups) imposing additional del
>Paul Menage wrote:
>> On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
>>> On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
Allow to limit the block I/O bandwidth for specific process containers
(cgroups) imposing additional delays on I/O requests for t
Andrea Righi wrote:
[snip]
> +static ssize_t iothrottle_read(struct cgroup *cont, struct cftype *cft,
> +struct file *file, char __user *buf,
> +size_t nbytes, loff_t *ppos)
> +{
> + ssize_t count, ret;
> + unsigned long delta, iorat
Paul Menage wrote:
> On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
>> On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
>>> Allow to limit the block I/O bandwidth for specific process containers
>>> (cgroups) imposing additional delays on I/O requests for those proces
On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
> > Allow to limit the block I/O bandwidth for specific process containers
> > (cgroups) imposing additional delays on I/O requests for those processes
> > that exceed th
On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
> Allow to limit the block I/O bandwidth for specific process containers
> (cgroups) imposing additional delays on I/O requests for those processes
> that exceed the limits defined in the control group filesystem.
>
> Example:
> # mkd
Allow to limit the block I/O bandwidth for specific process containers
(cgroups) imposing additional delays on I/O requests for those processes
that exceed the limits defined in the control group filesystem.
Example:
# mkdir /dev/cgroup
# mount -t cgroup -oio-throttle io-throttle /dev/cgroup
22 matches
Mail list logo
