Re: i/o bandwidth controller infrastructure

Re: i/o bandwidth controller infrastructure

[Divyesh Shah]

>
> This is the core io-throttle kernel infrastructure. It creates the
> basic
> interfaces to cgroups and implements the I/O measurement and
> throttling
> functions.

I am not sure if throttling an application's cpu usage by explicitly  
putting it to sleep
in order to restrain it from making more IO requests is the way to go  
here (though I can't think
of anything better right now).
With this bandwidth controller, a cpu-intensive job which otherwise  
does not care about its IO
performance needs to be pin-point accurate about IO bandwidth  
required in order to not suffer
from cpu-throttling. IMHO, if a cgroup is exceeding its limit for a  
given resource, the throttling
should be done _only_ for that resource.

-Divyesh

Re: i/o bandwidth controller infrastructure

[Andrea Righi]

Divyesh Shah wrote:
>> This is the core io-throttle kernel infrastructure. It creates the
>> basic
>> interfaces to cgroups and implements the I/O measurement and
>> throttling
>> functions.
> 
> I am not sure if throttling an application's cpu usage by explicitly  
> putting it to sleep
> in order to restrain it from making more IO requests is the way to go  
> here (though I can't think
> of anything better right now).
> With this bandwidth controller, a cpu-intensive job which otherwise  
> does not care about its IO
> performance needs to be pin-point accurate about IO bandwidth  
> required in order to not suffer
> from cpu-throttling. IMHO, if a cgroup is exceeding its limit for a  
> given resource, the throttling
> should be done _only_ for that resource.
> 
> -Divyesh

Divyesh,

I understand your point of view. It would be nice if we could just
"disable" the i/o for a cgroup that exceeds its limit, instead of
scheduling some sleep()s, so the tasks running in this cgroup would be
able to continue their non-i/o operations as usual.

However, how to do if the tasks continue to perform i/o ops under this
condition? we could just cache the i/o in memory and at the same time
reduce the i/o priority of those tasks' requests, but this would require
a lot of memory, more space in the page cache, and probably could lead
to potential OOM conditions. A safer approach IMHO is to force the tasks
to wait synchronously on each operation that directly or indirectly
generates i/o. The last one is the solution implemented by this
bandwidth controller.

We could collect additional statistics, or implement some heuristics to
predict the tasks' i/o patterns in order to not penalize cpu-bound jobs
too much, but the basic concept is the same.

Anyway, I agree there must be a better solution, but this is the best
I've found right now... nice ideas are welcome.

-Andrea

Re: i/o bandwidth controller infrastructure

[Eric Rannaud]

On Tue, 17 Jun 2008, Andrea Righi wrote:
> > With this bandwidth controller, a cpu-intensive job which otherwise  does
> > not care about its IO
> > performance needs to be pin-point accurate about IO bandwidth  required in
> > order to not suffer
> > from cpu-throttling. IMHO, if a cgroup is exceeding its limit for a  given
> > resource, the throttling
> > should be done _only_ for that resource.
> 
> I understand your point of view. It would be nice if we could just
> "disable" the i/o for a cgroup that exceeds its limit, instead of
> scheduling some sleep()s, so the tasks running in this cgroup would be
> able to continue their non-i/o operations as usual.
> 
> However, how to do if the tasks continue to perform i/o ops under this
> condition? we could just cache the i/o in memory and at the same time
> reduce the i/o priority of those tasks' requests, but this would require
> a lot of memory, more space in the page cache, and probably could lead
> to potential OOM conditions. A safer approach IMHO is to force the tasks
> to wait synchronously on each operation that directly or indirectly
> generates i/o. The last one is the solution implemented by this
> bandwidth controller.

What about AIO? Is this approach going to make the task sleep as well?
Would it better to return from aio_write()/_read() with EAGAIN?

Thanks.

Re: i/o bandwidth controller infrastructure

[Andrea Righi]

Eric Rannaud wrote:
> On Tue, 17 Jun 2008, Andrea Righi wrote:
>>> With this bandwidth controller, a cpu-intensive job which otherwise  does
>>> not care about its IO
>>> performance needs to be pin-point accurate about IO bandwidth  required in
>>> order to not suffer
>>> from cpu-throttling. IMHO, if a cgroup is exceeding its limit for a  given
>>> resource, the throttling
>>> should be done _only_ for that resource.
>> I understand your point of view. It would be nice if we could just
>> "disable" the i/o for a cgroup that exceeds its limit, instead of
>> scheduling some sleep()s, so the tasks running in this cgroup would be
>> able to continue their non-i/o operations as usual.
>>
>> However, how to do if the tasks continue to perform i/o ops under this
>> condition? we could just cache the i/o in memory and at the same time
>> reduce the i/o priority of those tasks' requests, but this would require
>> a lot of memory, more space in the page cache, and probably could lead
>> to potential OOM conditions. A safer approach IMHO is to force the tasks
>> to wait synchronously on each operation that directly or indirectly
>> generates i/o. The last one is the solution implemented by this
>> bandwidth controller.
> 
> What about AIO? Is this approach going to make the task sleep as well?
> Would it better to return from aio_write()/_read() with EAGAIN?

Good point. I should check, but it seems sleeps are incorrectly
performed also for AIO requests. I agree the correct behaviour would be
to return EAGAIN instead, as you suggested. I'll look at it if nobody
comes up with a solution.

Thanks,
-Andrea

Re: [PATCH 1/1] [x86] Configuration options to compile out x86 CPU support code

[Bodo Eggert]

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> This patch adds some configuration options that allow to compile out
> CPU vendor-specific code in x86 kernels (in arch/x86/kernel/cpu). The
> new configuration options are only visible when CONFIG_EMBEDDED is
> selected, as they are mostly interesting for space savings reasons.

> +menuconfig PROCESSOR_SELECT
> +     default y
> +     bool "Supported processor vendors" if EMBEDDED
> +     help
> +       This lets you choose what x86 vendor support code your kernel
> +       will include.
> +
> +config CPU_SUP_INTEL_32
> +     default y
> +     bool "Support Intel processors" if PROCESSOR_SELECT
> +     depends on !64BIT
> +     help
> +       This enables extended support for Intel processors
> +

I don't think having a generic kernel for only Intel CPUs makes much sense,
and OTOH, if you optimize for e.g. Athlon CPUs, you're likely to not need
Intel code on that machine - even on desktop systems.

What about an option to "Include code for CPUs from all supported vendors",
invisible and y for generic kernels?

Re: [PATCH 1/1] [x86] Configuration options to compile out x86 CPU support code

[Bodo Eggert]

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> This patch adds some configuration options that allow to compile out
> CPU vendor-specific code in x86 kernels (in arch/x86/kernel/cpu). The
> new configuration options are only visible when CONFIG_EMBEDDED is
> selected, as they are mostly interesting for space savings reasons.

> +menuconfig PROCESSOR_SELECT
> +     default y
> +     bool "Supported processor vendors" if EMBEDDED
> +     help
> +       This lets you choose what x86 vendor support code your kernel
> +       will include.
> +
> +config CPU_SUP_INTEL_32
> +     default y
> +     bool "Support Intel processors" if PROCESSOR_SELECT
> +     depends on !64BIT
> +     help
> +       This enables extended support for Intel processors
> +

I don't think having a generic kernel for only Intel CPUs makes much sense,
and OTOH, if you optimize for e.g. Athlon CPUs, you're likely to not need
Intel code on that machine - even on desktop systems.

What about an option to "Include code for CPUs from all supported vendors",
invisible and y for generic kernels?