Re: sched_setaffinity(), RT priorities and migration thread usage at 30%

[Nick Piggin <nickpiggin@yahoo.com.au>]

don fisher wrote:
> Hello,
> 
> Apologies in advance if this is a newbie question. I am attempting to 
> write a real-time simulation of an application we have in house. I have 
> a dual processor SMP system, hyperthreading enabled, running kernel 2.6.7.
> 
> The first thread begins at priority 1 (SCHED_RR) and subsequently spawns 
> another time critical task running at priority 2. The initial thread 
> uses setaffinity to set the desired cpu to 2. When the second task 
> begins, the migration thread becomes 30% active (as reported by top) for 
> the duration of its execution. When the priority 2 thread terminates the 
> first thread continues with the migration task consuming only 2% of the 
> CPU.
> 
> If there was any change, I was expecting that the higher priority of the 
> second thread would cause it to execute closer to 100% CPU. I built a 
> test code where each thread computes an identical dumb timing loop. The 
> priority 2 thread ends up executing 30% slower than the priority 1 
> thread due to contention with the migration thread.
> 
> Is this the expected behavior, and if so could you please inform me why? 
> I had not anticipated the any attempt by the kernel to shift the process 
> to another CPU, since sched_setafinity had been applied.
> 

OK I'll have to put something in that doesn't class the balancing
attempt as a failure if it encounters tasks that aren't allowed to
be moved.