interrupt cpu time accounting?

interrupt cpu time accounting?

[Jeff Garzik]

Does the kernel scheduler notice when a CPU spends a lot of time doing 
interrupt processing?

For many network configurations you get the best cache affinity, etc. if 
you lock network interrupts to a single CPU.  However, on a box with 
high network load, that could mean that that CPU is spending more time 
processing interrupts than doing Real Work(tm).

Will the scheduler "notice" this, and increasingly schedule processes 
away from the interrupt-heavy CPU?

	Jeff

Re: interrupt cpu time accounting?

[Robert Love]

On Sun, 2004-08-29 at 16:42 -0400, Jeff Garzik wrote:
> Does the kernel scheduler notice when a CPU spends a lot of time doing 
> interrupt processing?
> 
> For many network configurations you get the best cache affinity, etc. if 
> you lock network interrupts to a single CPU.  However, on a box with 
> high network load, that could mean that that CPU is spending more time 
> processing interrupts than doing Real Work(tm).
> 
> Will the scheduler "notice" this, and increasingly schedule processes 
> away from the interrupt-heavy CPU?

Nope, not explicitly anyhow.

Implicitly, at least, the load balancer will ensure that the runnable
processes on the processor do not get "backed up" due to the delayed
processing but you will still have the balanced minimum number of
processes there.

I don't know whether the answer is to use cpu affinity and not schedule
processes on that processor when you bind interrupts to it, or an
automatic algorithm in the load balance for doing it, but that is a neat
idea.

	Robert Love

Re: interrupt cpu time accounting?

[Jeff Garzik]

Robert Love wrote:
> On Sun, 2004-08-29 at 16:42 -0400, Jeff Garzik wrote:
> 
>>Does the kernel scheduler notice when a CPU spends a lot of time doing 
>>interrupt processing?
>>
>>For many network configurations you get the best cache affinity, etc. if 
>>you lock network interrupts to a single CPU.  However, on a box with 
>>high network load, that could mean that that CPU is spending more time 
>>processing interrupts than doing Real Work(tm).
>>
>>Will the scheduler "notice" this, and increasingly schedule processes 
>>away from the interrupt-heavy CPU?
> 
> 
> Nope, not explicitly anyhow.
> 
> Implicitly, at least, the load balancer will ensure that the runnable
> processes on the processor do not get "backed up" due to the delayed
> processing but you will still have the balanced minimum number of
> processes there.

What piece of code defines "balanced"?  :)


> I don't know whether the answer is to use cpu affinity and not schedule
> processes on that processor when you bind interrupts to it, or an
> automatic algorithm in the load balance for doing it, but that is a neat
> idea.

Less a neat idea, and more IMHO recognition of a problem that needs solving.

I am worried that processes will get starved if one CPU is _heavily_ 
loaded servicing interrupts, and the others are not.

Regards,

	Jeff

Re: interrupt cpu time accounting?

[Robert Love]

On Sun, 2004-08-29 at 17:26 -0400, Jeff Garzik wrote:

> What piece of code defines "balanced"?  :)

kernel/sched.c :: load_balance()

We used to try to keep the processors within 25% of each other, and try
very hard to ensure that no processor had zero processes.  The sched
domain code changed all that.

The only place the load balancer will help in your scenario is when the
processor is so busy processing interrupts and processes get backed up
on the processor (new processes moved there or, more likely, via forks).
The load balance won't help if the baseline minimum number of processes
is there but they are starving.

> Less a neat idea, and more IMHO recognition of a problem that needs solving.
> 
> I am worried that processes will get starved if one CPU is _heavily_ 
> loaded servicing interrupts, and the others are not.

If people are seeing it, then I 100% agree.

	Robert Love