On Sat, Jul 07, 2007 at 07:20:12PM +0200, Willy Tarreau wrote:
> On Sat, Jul 07, 2007 at 07:01:57PM +0200, Adrian Bunk wrote:
> > On Sat, Jul 07, 2007 at 11:45:20AM -0400, Frank Ch. Eigler wrote:
>...
> > You always have to decide between some debug code and some small bit of
> > performance.
Hi, Adrian -
On Sat, Jul 07, 2007 at 07:01:57PM +0200, Adrian Bunk wrote:
> [...]
> > Things are not so simple. One might not know that one has a
> > performance problem until one tries some analysis tools. Rebooting
> > into different kernels just to investigate does not work generally [...]
>
On Sat, Jul 07, 2007 at 07:01:57PM +0200, Adrian Bunk wrote:
> On Sat, Jul 07, 2007 at 11:45:20AM -0400, Frank Ch. Eigler wrote:
> > Adrian Bunk <[EMAIL PROTECTED]> writes:
> >
> > > [...]
> > > profiling = debugging of performance problems
> >
> > Indeed.
> >
> > > My words were perhaps a bit
On Sat, Jul 07, 2007 at 11:45:20AM -0400, Frank Ch. Eigler wrote:
> Adrian Bunk <[EMAIL PROTECTED]> writes:
>
> > [...]
> > profiling = debugging of performance problems
>
> Indeed.
>
> > My words were perhaps a bit sloppy, but profiling isn't part of
> > normal operation and if people use a
Adrian Bunk <[EMAIL PROTECTED]> writes:
> [...]
> profiling = debugging of performance problems
Indeed.
> My words were perhaps a bit sloppy, but profiling isn't part of
> normal operation and if people use a separate kernel for such
> purposes we don't need infrastructure for reducing
Adrian Bunk [EMAIL PROTECTED] writes:
[...]
profiling = debugging of performance problems
Indeed.
My words were perhaps a bit sloppy, but profiling isn't part of
normal operation and if people use a separate kernel for such
purposes we don't need infrastructure for reducing performance
On Sat, Jul 07, 2007 at 11:45:20AM -0400, Frank Ch. Eigler wrote:
Adrian Bunk [EMAIL PROTECTED] writes:
[...]
profiling = debugging of performance problems
Indeed.
My words were perhaps a bit sloppy, but profiling isn't part of
normal operation and if people use a separate kernel
On Sat, Jul 07, 2007 at 07:01:57PM +0200, Adrian Bunk wrote:
On Sat, Jul 07, 2007 at 11:45:20AM -0400, Frank Ch. Eigler wrote:
Adrian Bunk [EMAIL PROTECTED] writes:
[...]
profiling = debugging of performance problems
Indeed.
My words were perhaps a bit sloppy, but profiling
Hi, Adrian -
On Sat, Jul 07, 2007 at 07:01:57PM +0200, Adrian Bunk wrote:
[...]
Things are not so simple. One might not know that one has a
performance problem until one tries some analysis tools. Rebooting
into different kernels just to investigate does not work generally [...]
I'm
On Sat, Jul 07, 2007 at 07:20:12PM +0200, Willy Tarreau wrote:
On Sat, Jul 07, 2007 at 07:01:57PM +0200, Adrian Bunk wrote:
On Sat, Jul 07, 2007 at 11:45:20AM -0400, Frank Ch. Eigler wrote:
...
You always have to decide between some debug code and some small bit of
performance. There's a
On Sat, Jul 07, 2007 at 06:03:07AM +0200, Adrian Bunk wrote:
> On Fri, Jul 06, 2007 at 10:35:11PM -0400, Mathieu Desnoyers wrote:
> > * Adrian Bunk ([EMAIL PROTECTED]) wrote:
> > > On Fri, Jul 06, 2007 at 07:43:15PM -0400, Mathieu Desnoyers wrote:
> > > > * Adrian Bunk ([EMAIL PROTECTED]) wrote:
>
On Fri, Jul 06, 2007 at 10:35:11PM -0400, Mathieu Desnoyers wrote:
> * Adrian Bunk ([EMAIL PROTECTED]) wrote:
> > On Fri, Jul 06, 2007 at 07:43:15PM -0400, Mathieu Desnoyers wrote:
> > > * Adrian Bunk ([EMAIL PROTECTED]) wrote:
> > > > On Fri, Jul 06, 2007 at 06:14:10PM -0400, Chuck Ebbert wrote:
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
> On Fri, Jul 06, 2007 at 07:43:15PM -0400, Mathieu Desnoyers wrote:
> > * Adrian Bunk ([EMAIL PROTECTED]) wrote:
> > > On Fri, Jul 06, 2007 at 06:14:10PM -0400, Chuck Ebbert wrote:
> > > > On 07/06/2007 07:44 AM, Andi Kleen wrote:
> > > > > I think the
On Fri, Jul 06, 2007 at 07:43:15PM -0400, Mathieu Desnoyers wrote:
> * Adrian Bunk ([EMAIL PROTECTED]) wrote:
> > On Fri, Jul 06, 2007 at 06:14:10PM -0400, Chuck Ebbert wrote:
> > > On 07/06/2007 07:44 AM, Andi Kleen wrote:
> > > > I think the optimization is a good idea, although i dislike it
> >
On Fri, Jul 06, 2007 at 07:38:27PM -0400, Dave Jones wrote:
> On Sat, Jul 07, 2007 at 01:28:43AM +0200, Adrian Bunk wrote:
>
> > Only if you want to squeeze the last bit of performance out of
> > _debugging_ functionality.
> >
> > You avoid all the pain if you simply don't use debugging
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
> On Fri, Jul 06, 2007 at 06:14:10PM -0400, Chuck Ebbert wrote:
> > On 07/06/2007 07:44 AM, Andi Kleen wrote:
> > > I think the optimization is a good idea, although i dislike it
> > > that it is complicated for the dynamic markers. If it was just
> > >
On Sat, Jul 07, 2007 at 01:28:43AM +0200, Adrian Bunk wrote:
> Only if you want to squeeze the last bit of performance out of
> _debugging_ functionality.
>
> You avoid all the pain if you simply don't use debugging functionality
> on production systems.
I think you're mixing up profiling
On Fri, Jul 06, 2007 at 06:14:10PM -0400, Chuck Ebbert wrote:
> On 07/06/2007 07:44 AM, Andi Kleen wrote:
> > I think the optimization is a good idea, although i dislike it
> > that it is complicated for the dynamic markers. If it was just
> > static it would be much simpler.
>
> Another thing to
On 07/06/2007 07:44 AM, Andi Kleen wrote:
> I think the optimization is a good idea, although i dislike it
> that it is complicated for the dynamic markers. If it was just
> static it would be much simpler.
>
Another thing to consider is that there might be hundreds of these
probes/tracepoints
On Thu, Jul 05, 2007 at 11:46:44AM -0400, Mathieu Desnoyers wrote:
> * Bodo Eggert ([EMAIL PROTECTED]) wrote:
> > Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > Alexey Dobriyan <[EMAIL PROTECTED]> writes:
> > >> On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
> >
> > >> > Use
* Li, Tong N ([EMAIL PROTECTED]) wrote:
> > I found that memory latency is difficult to measure in modern x86
> > CPUs because they have very clever prefetchers that can often
> > outwit benchmarks.
>
> A pointer-chasing program that accesses a random sequence of addresses
> usually can produce a
> I found that memory latency is difficult to measure in modern x86
> CPUs because they have very clever prefetchers that can often
> outwit benchmarks.
A pointer-chasing program that accesses a random sequence of addresses
usually can produce a good estimate on memory latency. Also, prefetching
On Fri, Jul 06, 2007 at 10:50:30AM -0700, Li, Tong N wrote:
> > Also cache misses in this situation tend to be much more than 48
> cycles
> > (even an K8 with integrated memory controller with fastest DIMMs is
> > slower than that) Mathieu probably measured an L2 miss, not a load
> Also cache misses in this situation tend to be much more than 48
cycles
> (even an K8 with integrated memory controller with fastest DIMMs is
> slower than that) Mathieu probably measured an L2 miss, not a load
from
> RAM.
> Load from RAM can be hundreds of ns in the worst case.
>
The 48
Andrew Morton <[EMAIL PROTECTED]> writes:
> Is that 48 cycles measured when the target of the read is in L1 cache, as
> it would be in any situation which we actually care about? I guess so...
The normal situation is big database or other bloated software runs; clears
all the dcaches, then
Andrew Morton [EMAIL PROTECTED] writes:
Is that 48 cycles measured when the target of the read is in L1 cache, as
it would be in any situation which we actually care about? I guess so...
The normal situation is big database or other bloated software runs; clears
all the dcaches, then enters
Also cache misses in this situation tend to be much more than 48
cycles
(even an K8 with integrated memory controller with fastest DIMMs is
slower than that) Mathieu probably measured an L2 miss, not a load
from
RAM.
Load from RAM can be hundreds of ns in the worst case.
The 48 cycles
On Fri, Jul 06, 2007 at 10:50:30AM -0700, Li, Tong N wrote:
Also cache misses in this situation tend to be much more than 48
cycles
(even an K8 with integrated memory controller with fastest DIMMs is
slower than that) Mathieu probably measured an L2 miss, not a load
I found that memory latency is difficult to measure in modern x86
CPUs because they have very clever prefetchers that can often
outwit benchmarks.
A pointer-chasing program that accesses a random sequence of addresses
usually can produce a good estimate on memory latency. Also, prefetching
can
* Li, Tong N ([EMAIL PROTECTED]) wrote:
I found that memory latency is difficult to measure in modern x86
CPUs because they have very clever prefetchers that can often
outwit benchmarks.
A pointer-chasing program that accesses a random sequence of addresses
usually can produce a good
On Thu, Jul 05, 2007 at 11:46:44AM -0400, Mathieu Desnoyers wrote:
* Bodo Eggert ([EMAIL PROTECTED]) wrote:
Andi Kleen [EMAIL PROTECTED] wrote:
Alexey Dobriyan [EMAIL PROTECTED] writes:
On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
Use immediate values with
On 07/06/2007 07:44 AM, Andi Kleen wrote:
I think the optimization is a good idea, although i dislike it
that it is complicated for the dynamic markers. If it was just
static it would be much simpler.
Another thing to consider is that there might be hundreds of these
probes/tracepoints
On Fri, Jul 06, 2007 at 06:14:10PM -0400, Chuck Ebbert wrote:
On 07/06/2007 07:44 AM, Andi Kleen wrote:
I think the optimization is a good idea, although i dislike it
that it is complicated for the dynamic markers. If it was just
static it would be much simpler.
Another thing to consider
On Sat, Jul 07, 2007 at 01:28:43AM +0200, Adrian Bunk wrote:
Only if you want to squeeze the last bit of performance out of
_debugging_ functionality.
You avoid all the pain if you simply don't use debugging functionality
on production systems.
I think you're mixing up profiling and
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Fri, Jul 06, 2007 at 06:14:10PM -0400, Chuck Ebbert wrote:
On 07/06/2007 07:44 AM, Andi Kleen wrote:
I think the optimization is a good idea, although i dislike it
that it is complicated for the dynamic markers. If it was just
static it would
On Fri, Jul 06, 2007 at 07:38:27PM -0400, Dave Jones wrote:
On Sat, Jul 07, 2007 at 01:28:43AM +0200, Adrian Bunk wrote:
Only if you want to squeeze the last bit of performance out of
_debugging_ functionality.
You avoid all the pain if you simply don't use debugging functionality
On Fri, Jul 06, 2007 at 07:43:15PM -0400, Mathieu Desnoyers wrote:
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Fri, Jul 06, 2007 at 06:14:10PM -0400, Chuck Ebbert wrote:
On 07/06/2007 07:44 AM, Andi Kleen wrote:
I think the optimization is a good idea, although i dislike it
that it
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Fri, Jul 06, 2007 at 07:43:15PM -0400, Mathieu Desnoyers wrote:
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Fri, Jul 06, 2007 at 06:14:10PM -0400, Chuck Ebbert wrote:
On 07/06/2007 07:44 AM, Andi Kleen wrote:
I think the optimization is a
On Fri, Jul 06, 2007 at 10:35:11PM -0400, Mathieu Desnoyers wrote:
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Fri, Jul 06, 2007 at 07:43:15PM -0400, Mathieu Desnoyers wrote:
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Fri, Jul 06, 2007 at 06:14:10PM -0400, Chuck Ebbert wrote:
On
On Sat, Jul 07, 2007 at 06:03:07AM +0200, Adrian Bunk wrote:
On Fri, Jul 06, 2007 at 10:35:11PM -0400, Mathieu Desnoyers wrote:
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On Fri, Jul 06, 2007 at 07:43:15PM -0400, Mathieu Desnoyers wrote:
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
On
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Thu, 5 Jul 2007 13:21:20 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Please prepare and maintain a short document which describes the
> > justification for making all these changes to the kernel.
>
> oh, you did. It's there in the
On Thu, 5 Jul 2007 13:21:20 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Please prepare and maintain a short document which describes the
> justification for making all these changes to the kernel.
oh, you did. It's there in the add-kconfig-stuff patch.
-
To unsubscribe from this list: send
On Tue, 3 Jul 2007 14:57:48 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Measuring the overall impact on the system of this single modification
> results in the difference brought by one site within the standard
> deviation of the normal samples. It will become significant when the
>
* Bodo Eggert ([EMAIL PROTECTED]) wrote:
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Alexey Dobriyan <[EMAIL PROTECTED]> writes:
> >> On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
>
> >> > Use immediate values with lower d-cache hit in optimized version as a
> >> > condition
Andi Kleen <[EMAIL PROTECTED]> wrote:
> Alexey Dobriyan <[EMAIL PROTECTED]> writes:
>> On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
>> > Use immediate values with lower d-cache hit in optimized version as a
>> > condition for scheduler profiling call.
>>
>> I think it's
Andi Kleen [EMAIL PROTECTED] wrote:
Alexey Dobriyan [EMAIL PROTECTED] writes:
On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
Use immediate values with lower d-cache hit in optimized version as a
condition for scheduler profiling call.
I think it's better to put
* Bodo Eggert ([EMAIL PROTECTED]) wrote:
Andi Kleen [EMAIL PROTECTED] wrote:
Alexey Dobriyan [EMAIL PROTECTED] writes:
On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
Use immediate values with lower d-cache hit in optimized version as a
condition for scheduler
On Tue, 3 Jul 2007 14:57:48 -0400
Mathieu Desnoyers [EMAIL PROTECTED] wrote:
Measuring the overall impact on the system of this single modification
results in the difference brought by one site within the standard
deviation of the normal samples. It will become significant when the
number of
On Thu, 5 Jul 2007 13:21:20 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
Please prepare and maintain a short document which describes the
justification for making all these changes to the kernel.
oh, you did. It's there in the add-kconfig-stuff patch.
-
To unsubscribe from this list: send the
* Andrew Morton ([EMAIL PROTECTED]) wrote:
On Thu, 5 Jul 2007 13:21:20 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
Please prepare and maintain a short document which describes the
justification for making all these changes to the kernel.
oh, you did. It's there in the
Alexey Dobriyan <[EMAIL PROTECTED]> writes:
> On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
> > Use immediate values with lower d-cache hit in optimized version as a
> > condition for scheduler profiling call.
>
> I think it's better to put profile.c under CONFIG_PROFILING
On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
> Use immediate values with lower d-cache hit in optimized version as a
> condition for scheduler profiling call.
I think it's better to put profile.c under CONFIG_PROFILING as
_expected_, so CONFIG_PROFILING=n users won't get any
On Tue, Jul 03, 2007 at 02:57:48PM -0400, Mathieu Desnoyers wrote:
> * Alexey Dobriyan ([EMAIL PROTECTED]) wrote:
> > On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
> > > Use immediate values with lower d-cache hit in optimized version as a
> > > condition for scheduler
On Tue, Jul 03, 2007 at 02:57:48PM -0400, Mathieu Desnoyers wrote:
> * Alexey Dobriyan ([EMAIL PROTECTED]) wrote:
> > On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
> > > Use immediate values with lower d-cache hit in optimized version as a
> > > condition for scheduler
On Tue, Jul 03, 2007 at 02:57:48PM -0400, Mathieu Desnoyers wrote:
* Alexey Dobriyan ([EMAIL PROTECTED]) wrote:
On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
Use immediate values with lower d-cache hit in optimized version as a
condition for scheduler profiling call.
On Tue, Jul 03, 2007 at 02:57:48PM -0400, Mathieu Desnoyers wrote:
* Alexey Dobriyan ([EMAIL PROTECTED]) wrote:
On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
Use immediate values with lower d-cache hit in optimized version as a
condition for scheduler profiling call.
On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
Use immediate values with lower d-cache hit in optimized version as a
condition for scheduler profiling call.
I think it's better to put profile.c under CONFIG_PROFILING as
_expected_, so CONFIG_PROFILING=n users won't get any
Alexey Dobriyan [EMAIL PROTECTED] writes:
On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
Use immediate values with lower d-cache hit in optimized version as a
condition for scheduler profiling call.
I think it's better to put profile.c under CONFIG_PROFILING as
* Alexey Dobriyan ([EMAIL PROTECTED]) wrote:
> On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
> > Use immediate values with lower d-cache hit in optimized version as a
> > condition for scheduler profiling call.
>
> How much difference in performance do you see?
>
Hi Alexey,
On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
> Use immediate values with lower d-cache hit in optimized version as a
> condition for scheduler profiling call.
How much difference in performance do you see?
-
To unsubscribe from this list: send the line "unsubscribe
On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
Use immediate values with lower d-cache hit in optimized version as a
condition for scheduler profiling call.
How much difference in performance do you see?
-
To unsubscribe from this list: send the line unsubscribe
* Alexey Dobriyan ([EMAIL PROTECTED]) wrote:
On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote:
Use immediate values with lower d-cache hit in optimized version as a
condition for scheduler profiling call.
How much difference in performance do you see?
Hi Alexey,
Please
62 matches
Mail list logo
