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
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,
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
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 this
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 box while
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, those are
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 lock isn't
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
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
* 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
* 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
* 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 'steady state'
* 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-lock-prof.c
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 havent
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 we'll
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
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
in
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):
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
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 time
* 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
* 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-bit
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
>
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
>
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
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
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
each
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
each
30 matches
Mail list logo
