Jon Elson wrote:

>John Kasunich wrote:
>  
>
>>My own theory (and it is only a theory) about why the cpu hog works is 
>>related to cache.  The hog uses very little memory, and since it keeps 
>>one CPU busy, that CPU never runs any other code.  So the RT code 
>>doesn't get flushed out of cache, and doesn't have to get fetched back 
>>into cache later.
>>
>>  
>>    
>>
>I think you have to be right, here.  The trick is to make sure the RT 
>tasks never hop from one CPU to another.  Probably having a process 
>always ready to run on one CPU makes the choice easy for the RT 
>scheduler to pick the same CPU always for the RT threads.
>  
>
This is not the problem.  When I discovered the "fix" of a CPU hog 
process, I was using isolcpus=1.  This prevented the Linux scheduler 
from using the second core.  RTAPI, when compiled on a machine with 
NR_CPUS>1, will always schedule RT tasks on the highest numbered CPU.  
(At least on RTAI it does this, I don't know that the changes made it 
into the RTLinux code)

>The CPU hog doesn't get complete use of a CPU, it has to share the CPU 
>with all other user-mode processes.  What it does is guarantee that that 
>CPU always has a process ready to run.
>  
>
This is true.

>It seems there ought to be a cleaner way to achieve this result, but I 
>have no idea how easy it is to configure the RT scheduler's rules.  What 
>about the scheme that reserves one core for RT threads only?  Does that 
>alter this result?
>  
>
Nope :)

- Steve


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to