Date: Thu, 30 Oct 2014 12:31:04 +0100
From: Andres Freund <andres@2ndquadrant.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Lockless StrategyGetBuffer() clock sweep
Message-ID: <20141030113104.GA8151@alap3.anarazel.de>
References: <20141027133218.GA2639@awork2.anarazel.de>
 <CA+TgmoaZS7Dx2EqcXjxc2PMrFq=ciJibi6rbwcRO-Hdn64H0tg@mail.gmail.com>
 <20141029190927.GF17724@awork2.anarazel.de>
 <CAA4eK1LnhEMNd2QWCLYVPQzMeRs+jdZFsuj+e_QHPdC3vYgveg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAA4eK1LnhEMNd2QWCLYVPQzMeRs+jdZFsuj+e_QHPdC3vYgveg@mail.gmail.com>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 2014-10-30 10:23:56 +0530, Amit Kapila wrote:
> I have a feeling that this might also have some regression at higher
> loads (like scale_factor = 5000, shared_buffers = 8GB,
> client_count = 128, 256) for the similar reasons as bgreclaimer patch,
> means although both reduces contention around spin lock, however
> it moves contention somewhere else.  I have yet to take data before
> concluding anything (I am just waiting for your other patch (wait free
> LW_SHARED) to be committed).

I have a hard time to see how this could be. In the uncontended case the
number of cachelines touched and the number of atomic operations is
exactly the same. In the contended case the new implementation does far
fewer atomic ops - and doesn't do spinning.

What's your theory?

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers