Re: Scaling shared buffer eviction

8, however that can be due to variation as well.

> > Here we can see that the performance dips at higher client
> > count(>=32) which was quite surprising for me, as I was expecting
> > it to improve, because bgreclaimer reduces the contention by making
> > buffers available on free list.  So I tried to analyze the situation by
> > using perf and found that in above configuration, there is a contention
> > around freelist spinlock with HEAD and the same is removed by Patch,
> > but still the performance goes down with Patch.  On further analysis, I
> > observed that actually after Patch there is an increase in contention
> > around ProcArrayLock (shared LWlock) via GetSnapshotData which
> > sounds bit odd, but that's what I can see in profiles.  Based on analysis,
> > few ideas which I would like to further investigate are:
> > a.  As there is an increase in spinlock contention, I would like to check
> > with Andres's latest patch which reduces contention around shared
> > lwlocks.
> > b.  Reduce some instructions added by patch in StrategyGetBuffer(),
> > like instead of awakening bgreclaimer at low threshold, awaken when
> > it tries to do clock sweep.
> >
>
> Are you sure you didn't mix up the profiles here? 

I have tried this 2 times, basically I am quite confident from myside,

but human errors can't be ruled out.  I have used below statements:

Steps used for profiling

during configure, use CFLAS="-fno-omit-frame-pointer"

Terminal -1

Start Server

Terminal -2

./pgbench -c 64 -j 64 -T 300 -S -M prepared postgres

Terminal-3

perf record -a -g sleep 60  --This command is run after a minute or so of 

                                      -- test start

After test is finished - perf report -g graph,0.5,callee

Do you see any problem in the way I am collecting perf reports?

In any case, I can try once more if you still doubt the profiles.