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

From: Mark_H_Johnson
Date: Wed Jan 05 2005 - 08:59:55 EST


> On Tue, 2005-01-04 at 14:11 -0600, Mark_H_Johnson@xxxxxxxxxxxx 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@xxxxxxxxxxxx>

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