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) and
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 n
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.
v4-00
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
> > nonetheles
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 for
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.
I
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 w
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 and
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 item
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
