Re: Real-Time Preemption, comparison to 2.6.10-mm1

["K.R. Foley" <kr@cybsft.com>]

Mark_H_Johnson@raytheon.com wrote:
>>On Tue, 2005-01-04 at 14:11 -0600, Mark_H_Johnson@raytheon.com wrote:
>>
>>>The non RT application starvation for mm1 was much less
>>>pronounced but still present. I could watch the disk light
>>>on the last two tests & see it go out (and stay out) for an
>>>extended period. It does not make sense to me that a single RT
>>>application (on a two CPU machine) and a nice'd non RT application
>>>can cause this starvation behavior. This behavior was not
>>>present on the 2.4 kernels and seems to be a regression to me.
> 
> 
>>I think I am seeing this problem too.  It doesn't just apply to RT
>>tasks, it seems that CPU bound tasks starve each other.  I noticed that
>>with the RT kernel, a kernel compile or dpkg will starve evolution, to
>>the point where it takes 30 seconds to display a message.  If I go and
>>background the CPU hog, the message renders _instantly_.
> 
> 
>>It's definitely present with 2.6.10-rc2 + RT (PK config) and absent with
>>2.6.10 vanilla.  I need to figure out whether -mm has the problem.
> 
> My point was that -mm definitely has the problem (though to a lesser
> degree). The tests I ran showed it on both the disk read and disk copy
> stress tests. I guess I should try a vanilla 2.6.10 run as well to see
> if it is something introduced in the -mm series (it certainly is not a
> recent change...).
> 
> --Mark H Johnson
>   <mailto:Mark_H_Johnson@raytheon.com>
> 
> 
I'm curious if anyone is seeing this behavior on UP systems, or is it 
only happening on SMP?

kr