Re: testing ProcArrayLock patches

On Friday, November 18, 2011 08:36:59 PM Kevin Grittner wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> > samples % image name symbol name
> > 495463 3.6718 postgres hash_search_with_hash_value
>
> When lines like these show up in the annotated version, I'm
> impressed that we're still finding gains as big as we are:
>
> 44613 0.3306 : if (segp == NULL)
>
> : hash_corrupted(hashp);
>
> 101910 0.7552 : keysize = hashp->keysize; /* ditto */
When doing line-level profiles I would suggest looking at the instructions.
Quite often the line shown doesn't have much to do whats executed as the
compiler tries to schedule instructions cleverly.
Also in many situations the shown cost doesn't actually lie in the instruction
shown but in some previous one. The shown instruction e.g. has to wait for the
result of the earlier instructions. Pipelining makes that hard to correctly
observe.

A simplified example would be something like:

bool func(int a, int b, int c){
int res = a / b;
if(res == c){
return true;
}
return false;
}

Likely the instruction showing up in the profile would be the comparison. Which
obviously is not the really expensive part...

> There goes over 1% of my server run time, right there!
>
> Of course, these make no sense unless there is cache line
> contention, which is why that area is bearing fruit.
I don't think cache line contention is the most likely candidate here. Simple
cache-misses seem far more likely. In combination with pipeline stalls...

Newer cpus (nehalem+) can measure stalled cycles which can be really useful
when analyzing performance. I don't remember how to do that with oprofile right
now though as I use perf these days (its -e stalled-cycles{frontend|backend}
there}).

Andres