Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]

[Florian Schmidt]

On Mon, 1 Nov 2004 14:40:47 -0800
Bill Huey (hui) <bhuey@xxxxxxxx> wrote:

> Unlikely, it's got to lock the entire kernel to make sure that things aren't
> changing under it. Getting measurements is useful at this stage, but don't expect
> it to be a finished product any time soon and please keep that in mind. Stability
> should be, if it's not already, the single most important things in this project
> at this phase. Getting numbers now for a specific single application is going to
> be of limit use until the system is stable enough for general characterization.
> 
> Keep doing it, but keep in mind that anything you're going to get at this time
> is going to be very coarse. Don't put too much weight on it.
> 
> That's my take.

ack. understood. i was just asking since i don't have a second machine and
thus am not really able to help with the deadlock debugging. so i figured i
could at least do some timing. btw: even with deadlock detection, the
results for 0.6.5 looked pretty good [in 10 minutes uptime ca.3-4% max
jitter [30something usecs].  until the deadlock that is [i head three finds
plus kernel compile at nice -10 running]..

flo
-
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/