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

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

Mark_H_Johnson@Raytheon.com wrote:
> K.R. Foley wrote:
> 
>>Mark_H_Johnson@raytheon.com wrote:
> 
> [snip - long explanation of how a nice application can starve a non
> nice application for minutes at a time on an SMP system]
> 
> 
>>>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...).
>>
>>I'm curious if anyone is seeing this behavior on UP systems, or is it
>>only happening on SMP?
> 
> The build of 2.6.10 vanilla just completed and I reran my tests with
> SMP and with MAXCPUS=1 (UP w/ SMP kernel).

Well that blows one of the theories I was looking at. :( -mm is carrying 
a patch that lengthens the cache_hot_time to roughly a ms instead of a 
usec, which could effect how fast tasks might be migrated to an idle cpu.
> 
> The vanilla 2.6.10 kernel has the non RT starvation problem as well
> for both test runs. It looks like this is not something in -mm but a
> change between 2.4 and 2.6.
> 
> I did notice the test results were a little inconsistent between the
> two runs...
>              2.6.10 SMP    2.6.10 UP (w/ SMP kernel)
> disk write    starved          OK
> disk copy        OK         starved
> disk read     starved       starved
> but in both cases, a non nice (non RT) disk application was
> starved by a nice (non RT) cpu application for minutes.

Do you have a simple way of triggering and trapping the starvation? That 
of course is probably asking for a lot. :)

kr

> 
> I wonder who I should be talking to next (or submit a bug report?)
> about this.
> 
>   --Mark
> 
>