Hi,
On 2025-07-16 18:27:45 +0300, Yura Sokolov wrote:
> 16.07.2025 17:58, Andres Freund пишет:
> >> Now, if I simply remove the spinlock in SIGetDataEntries, I see a drop of
> >> just ~6% under concurrent DDL. I think this strongly suggests that the
> >> spinlock is the bottleneck.
> >
> > This c
16.07.2025 17:58, Andres Freund пишет:
> Hi,
>
> On 2025-06-25 16:41:46 +0300, Sergey Shinderuk wrote:
>> On 16.06.2025 17:41, Andres Freund wrote:
>>> TBH, I don't see a point in continuing with this thread without something
>>> that
>>> others can test. I rather doubt that the right fix here i
Hi,
On 2025-06-25 16:41:46 +0300, Sergey Shinderuk wrote:
> On 16.06.2025 17:41, Andres Freund wrote:
> > TBH, I don't see a point in continuing with this thread without something
> > that
> > others can test. I rather doubt that the right fix here is to just change
> > the
> > lock model over,
On 16.06.2025 17:41, Andres Freund wrote:
TBH, I don't see a point in continuing with this thread without something that
others can test. I rather doubt that the right fix here is to just change the
lock model over, but without a repro I can't evaluate that.
Hello,
I think I can reproduce th
Hi,
On 2025-06-16 17:28:31 +0300, Yura Sokolov wrote:
> 04.06.2025 00:04, Andres Freund пишет:
> > Hi,
> >
> > On 2025-06-02 21:20:33 +0300, Yura Sokolov wrote:
> >> But still problem of spin lock contention is here.
> >
> > I still would like to see a reproducer for this.
>
> For problem in si
04.06.2025 00:04, Andres Freund пишет:
> Hi,
>
> On 2025-06-02 21:20:33 +0300, Yura Sokolov wrote:
>> But still problem of spin lock contention is here.
>
> I still would like to see a reproducer for this.
For problem in sinvaladt.c we have no synthetic reproducer. But version
with changed maxMs
Hi,
On 2025-06-02 21:20:33 +0300, Yura Sokolov wrote:
> But still problem of spin lock contention is here.
I still would like to see a reproducer for this.
> So I propose to introduce another spin lock type capable for Exclusive and
> Shared lock modes (i.e. Write/Read modes) and use it in this
Good day, Andres.
Good day, hackers.
05.05.2025 10:30, Yura Sokolov wrote:
> 21.03.2025 19:33, Andres Freund пишет:
>> Hi,
>>
>> On 2025-03-21 14:35:16 +0300, Yura Sokolov wrote:
>>> From 080c9e0de5e6e10751347e1ff50b65df424744cb Mon Sep 17 00:00:00 2001
>>> From: Yura Sokolov
>>> Date: Mon, 3 Feb
21.03.2025 19:33, Andres Freund пишет:
> Hi,
>
> On 2025-03-21 14:35:16 +0300, Yura Sokolov wrote:
>> From 080c9e0de5e6e10751347e1ff50b65df424744cb Mon Sep 17 00:00:00 2001
>> From: Yura Sokolov
>> Date: Mon, 3 Feb 2025 11:58:33 +0300
>> Subject: [PATCH v2] sinvaladt.c: use atomic operations on m
25.03.2025 13:52, Yura Sokolov пишет:
> Good day, Andres
>
> 24.03.2025 16:08, Andres Freund wrote:
>> On 2025-03-24 13:41:17 +0300, Yura Sokolov wrote:
>>> 21.03.2025 19:33, Andres Freund wrote:
I'd also like to know a bit more about the motivation here - I can easily
believe that you h
Hi,
On 2025-03-24 13:41:17 +0300, Yura Sokolov wrote:
> 21.03.2025 19:33, Andres Freund wrote:
> > I'd also like to know a bit more about the motivation here - I can easily
> > believe that you hit contention around the shared inval queue, but I find it
> > somewhat hard to believe that a spinlock
Hi, Andres
21.03.2025 19:33, Andres Freund wrote:
> Hi,
>
> On 2025-03-21 14:35:16 +0300, Yura Sokolov wrote:
>> From 080c9e0de5e6e10751347e1ff50b65df424744cb Mon Sep 17 00:00:00 2001
>> From: Yura Sokolov
>> Date: Mon, 3 Feb 2025 11:58:33 +0300
>> Subject: [PATCH v2] sinvaladt.c: use atomic ope
Hi,
On 2025-03-21 14:35:16 +0300, Yura Sokolov wrote:
> From 080c9e0de5e6e10751347e1ff50b65df424744cb Mon Sep 17 00:00:00 2001
> From: Yura Sokolov
> Date: Mon, 3 Feb 2025 11:58:33 +0300
> Subject: [PATCH v2] sinvaladt.c: use atomic operations on maxMsgNum
>
> msgnumLock spinlock could be highly
Just rebased the patch.
---
regards
Yura Sokolov aka funny-falconFrom 080c9e0de5e6e10751347e1ff50b65df424744cb Mon Sep 17 00:00:00 2001
From: Yura Sokolov
Date: Mon, 3 Feb 2025 11:58:33 +0300
Subject: [PATCH v2] sinvaladt.c: use atomic operations on maxMsgNum
msgnumLock spinlock could be hig
03.02.2025 19:49, Heikki Linnakangas пишет:
> On 03/02/2025 13:05, Yura Sokolov wrote:
>> Investigating some performance issues of a client, our engineers found
>> msgnumLock to be contended.
>>
>> Looking closer it is obvious it is not needed at all: it used only as
>> memory barrier. It is even s
On 03/02/2025 13:05, Yura Sokolov wrote:
Investigating some performance issues of a client, our engineers found
msgnumLock to be contended.
Looking closer it is obvious it is not needed at all: it used only as
memory barrier. It is even stated in comment at file start:
* We deal with that by ha
Good day,
Investigating some performance issues of a client, our engineers found
msgnumLock to be contended.
Looking closer it is obvious it is not needed at all: it used only as
memory barrier. It is even stated in comment at file start:
* We deal with that by having a spinlock that readers mus
17 matches
Mail list logo
