On Tue, Jan 02, 2007 at 03:12:34PM -0800, Bill Huey wrote:
> On Tue, Jan 02, 2007 at 02:51:05PM -0800, Chen, Tim C wrote:
> > Bill,
> >
> > I'm having some problem getting this patch to run stablely. I'm
> > encoutering errors like that in the trace that follow:
>
> It might the case that the lo
On Tue, Jan 02, 2007 at 02:51:05PM -0800, Chen, Tim C wrote:
> Bill,
>
> I'm having some problem getting this patch to run stablely. I'm
> encoutering errors like that in the trace that follow:
>
> Thanks.
> Tim
>
> Unable to handle kernel NULL pointer dereference at 0008
Yes, thos
Bill Huey (hui) wrote:
> On Tue, Dec 26, 2006 at 04:51:21PM -0800, Chen, Tim C wrote:
>> Ingo Molnar wrote:
>>> If you'd like to profile this yourself then the lowest-cost way of
>>> profiling lock contention on -rt is to use the yum kernel and run
>>> the attached trace-it-lock-prof.c code on the
Ingo Molnar wrote:
>
> (could you send me the whole trace if you still have it? It would be
> interesting to see a broader snippet from the life of individual java
> threads.)
>
> Ingo
Sure, I'll send it to you separately due to the size of the complete
trace.
Tim
-
To unsubscribe from th
On Sat, Dec 30, 2006 at 06:56:08AM -0800, Daniel Walker wrote:
> On Sat, 2006-12-30 at 12:19 +0100, Ingo Molnar wrote:
>
> >
> > - Documentation/CodingStyle compliance - the code is not ugly per se
> >but still looks a bit 'alien' - please try to make it look Linuxish,
> >if i apply this
On Sat, 2006-12-30 at 12:19 +0100, Ingo Molnar wrote:
>
> - Documentation/CodingStyle compliance - the code is not ugly per se
>but still looks a bit 'alien' - please try to make it look Linuxish,
>if i apply this we'll probably stick with it forever. This is the
>major reason i have
* Bill Huey <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 26, 2006 at 04:51:21PM -0800, Chen, Tim C wrote:
> > Ingo Molnar wrote:
> > > If you'd like to profile this yourself then the lowest-cost way of
> > > profiling lock contention on -rt is to use the yum kernel and run the
> > > attached trace-it
* Chen, Tim C <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >
> > If you'd like to profile this yourself then the lowest-cost way of
> > profiling lock contention on -rt is to use the yum kernel and run the
> > attached trace-it-lock-prof.c code on the box while your workload is
> > in 'stea
Ingo Molnar wrote:
>
> If you'd like to profile this yourself then the lowest-cost way of
> profiling lock contention on -rt is to use the yum kernel and run the
> attached trace-it-lock-prof.c code on the box while your workload is
> in 'steady state' (and is showing those extended idle times):
>
On Tue, Dec 26, 2006 at 04:51:21PM -0800, Chen, Tim C wrote:
> Ingo Molnar wrote:
> > If you'd like to profile this yourself then the lowest-cost way of
> > profiling lock contention on -rt is to use the yum kernel and run the
> > attached trace-it-lock-prof.c code on the box while your workload is
Ingo Molnar wrote:
>
> cool - thanks for the feedback! Running the 64-bit kernel, right?
>
Yes, 64-bit kernel was used.
>
> while some slowdown is to be expected, did in each case idle time
> increase significantly?
Volanomark and Re-Aim7 ran close to 0% idle time for 2.6.19 kernel.
Idle tim
* Chen, Tim C <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19
> kernel and noticed several slowdowns. The test machine is a 2 socket
> woodcrest machine with your default configuration.
cool - thanks for the feedback! Running the 64-bi
Chen, Tim C wrote:
> Ingo,
>
> We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19
> kernel and noticed several slowdowns. The test machine is a 2 socket
> woodcrest machine with your default configuration.
>
> Netperf TCP Streaming was slower by 40% ( 1 server and 1 client
> ea
Chen, Tim C wrote:
> Ingo,
>
> We did some benchmarking on 2.6.19-rt14, compared it with 2.6.19
> kernel and noticed several slowdowns. The test machine is a 2 socket
> woodcrest machine with your default configuration.
>
> Netperf TCP Streaming was slower by 40% ( 1 server and 1 client
> ea
On Fri, 2006-12-22 at 13:39 -0800, Chen, Tim C wrote:
> Wonder if you have any suggestions on what could cause the slowdown.
> We've tried disabling CONFIG_NO_HZ and it didn't help much.
Did you compare PREEMPT_RT with vanilla PREEMPT ? Or one version of
PREEMPT_RT vs. another ?
Daniel
-
To u
15 matches
Mail list logo
