Message-ID: <413CEEF6.6080501@yahoo.com.au>
Date: Tue, 07 Sep 2004 09:12:54 +1000
From: Nick Piggin <nickpiggin@yahoo.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040810 Debian/1.7.2-2
MIME-Version: 1.0
To: don fisher <dfisher@as.arizona.edu>
CC: linux-kernel@vger.kernel.org
Subject: Re: sched_setaffinity(), RT priorities and migration thread usage
 at 30%
References: <413CE863.3050400@as.arizona.edu>
In-Reply-To: <413CE863.3050400@as.arizona.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1666
Lines: 34

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/