On Sat, 20 Jan 2024 at 07:28, vignesh C wrote:
>
> On Sat, 26 Nov 2022 at 00:24, Pavel Borisov wrote:
> >
> > Hi, hackers!
> > In the measurements above in the thread, I've been using LIFO wake
> > queue in a primary lockless patch (and it was attached as the previous
> > versions of a patch)
On Sat, 26 Nov 2022 at 00:24, Pavel Borisov wrote:
>
> Hi, hackers!
> In the measurements above in the thread, I've been using LIFO wake
> queue in a primary lockless patch (and it was attached as the previous
> versions of a patch) and an "inverted wake queue" (in faсt FIFO) as
> the alternative
Hi, hackers!
In the measurements above in the thread, I've been using LIFO wake
queue in a primary lockless patch (and it was attached as the previous
versions of a patch) and an "inverted wake queue" (in faсt FIFO) as
the alternative benchmarking option. I think using the latter is more
fair and
Hi, hackers!
Andres Freund recently committed his nice LWLock optimization
a4adc31f6902f6f. So I've rebased the patch on top of the current
master (PFA v5).
Regards,
Pavel Borisov,
Supabase.
v5-0001-Lockless-queue-of-LWLock-waiters.patch
Description: Binary data
Hi, hackers!
I've noticed that alignment requirements for using
pg_atomic_init_u64() for LWlock state (there's an assertion that it's
aligned at 8 bytes) do not correspond to the code in SimpleLruInit()
on 32-bit arch when MAXIMUM_ALIGNOF = 4.
Fixed this in v4 patch (PFA).
Regards,
Pavel.
Hi, Pavel!
On Fri, Nov 11, 2022 at 2:40 PM Pavel Borisov wrote:
> I've done some more measurements to check the hypotheses regarding the
> performance of a previous patch v2, and explain the results of tests
> in [1].
>
> The results below are the same (tps vs connections) plots as in [1],
> and
CFbot isn't happy because of additional patches in the previous
message, so here I attach v3 patch alone.
Regards,
Pavel
v3-0001-Lockless-queue-of-LWLock-waiters.patch
Description: Binary data
Hi,
On 2022-11-05 12:05:43 +0300, Alexander Korotkov wrote:
> On Fri, Nov 4, 2022 at 10:07 PM Andres Freund wrote:
> > The use of cmpxchg vs lock inc/lock add/xadd is one of the major reasons why
> > lwlocks are slower than a spinlock (but obviously are better under
> > contention
> >
Hi, Andres!
On Fri, Nov 4, 2022 at 10:07 PM Andres Freund wrote:
> The use of cmpxchg vs lock inc/lock add/xadd is one of the major reasons why
> lwlocks are slower than a spinlock (but obviously are better under contention
> nonetheless).
>
>
> I have a benchmark program that starts a thread
Hi,
On 2022-11-03 14:50:11 +0400, Pavel Borisov wrote:
> Or maybe there is another explanation for now small performance
> difference around 20 connections described in [0]?
> Thoughts?
Using xadd is quite a bit cheaper than cmpxchg, and now every lock release
uses a compare-exchange, I think.
Hi, Pavel!
On Thu, Nov 3, 2022 at 1:51 PM Pavel Borisov wrote:
> > I'm planning to gather more detailed statistics on different
> > LWLockAcquire calls soon to understand prospects for further
> > optimizations.
>
> So, I've made more measurements.
>
> 1. Applied measuring patch 0001 to a patch
Hi, hackers!
> I'm planning to gather more detailed statistics on different
> LWLockAcquire calls soon to understand prospects for further
> optimizations.
So, I've made more measurements.
1. Applied measuring patch 0001 to a patch with lockless queue
optimization (v2) from [0] in this thread
Hi Andres,
Thank you for your feedback.
On Tue, Nov 1, 2022 at 2:15 AM Andres Freund wrote:
> On 2022-10-31 14:38:23 +0400, Pavel Borisov wrote:
> > If the lock state contains references to the queue head and tail, we can
> > implement a lockless queue of waiters for the LWLock. Adding new
Hi,
Thanks for working on this - I think it's something we need to improve.
On 2022-10-31 14:38:23 +0400, Pavel Borisov wrote:
> If the lock state contains references to the queue head and tail, we can
> implement a lockless queue of waiters for the LWLock. Adding new items to
> the queue head
Hi, hackers!
When we take LWlock, we already use atomic CAS operation to atomically
modify the lock state even in the presence of concurrent lock-takers. But
if we can not take the lock immediately, we need to put the waiters on a
waiting list, and currently, this operation is done not atomically
15 matches
Mail list logo
