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. Ther
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 s
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 sep
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 performan
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 opti
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 funct
* 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
> > > stat
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 ac
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 immed
* 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
c
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 cycle
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 ente
* 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 add-kc
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
> numbe
* 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 f
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 bett
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
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 profilin
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 profilin
* 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 linux-ker
Use immediate values with lower d-cache hit in optimized version as a
condition for scheduler profiling call.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
---
drivers/kvm/svm.c |2 +-
drivers/kvm/vmx.c |2 +-
include/linux/profile.h |9 +++--
kernel/profile.c
32 matches
Mail list logo
