Re: [RFC] Lock-free XLog Reservation from WAL

On Thu, 23 Jan 2025 at 21:44, Japin Li <japinli(at)hotmail(dot)com> wrote:
> On Thu, 23 Jan 2025 at 15:03, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> wrote:
>> 23.01.2025 11:46, Japin Li пишет:
>>> On Wed, 22 Jan 2025 at 22:44, Japin Li <japinli(at)hotmail(dot)com> wrote:
>>>> On Wed, 22 Jan 2025 at 17:02, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> wrote:
>>>>> I believe, I know why it happens: I was in hurry making v2 by
>>>>> cherry-picking internal version. I reverted some changes in
>>>>> CalcCuckooPositions manually and forgot to add modulo
>>>>> PREV_LINKS_HASH_CAPA.
>>>>>
>>>>> Here's the fix:
>>>>>
>>>>> pos->pos[0] = hash % PREV_LINKS_HASH_CAPA;
>>>>> - pos->pos[1] = pos->pos[0] + 1;
>>>>> + pos->pos[1] = (pos->pos[0] + 1) % PREV_LINKS_HASH_CAPA;
>>>>> pos->pos[2] = (hash >> 16) % PREV_LINKS_HASH_CAPA;
>>>>> - pos->pos[3] = pos->pos[2] + 2;
>>>>> + pos->pos[3] = (pos->pos[2] + 2) % PREV_LINKS_HASH_CAPA;
>>>>>
>>>>> Any way, here's v3:
>>>>> - excess file "v0-0001-Increase..." removed. I believe it was source
>>>>> of white-space apply warnings.
>>>>> - this mistake fixed
>>>>> - more clear slots strategies + "8 positions in two cache-lines" strategy.
>>>>>
>>>>> You may play with switching PREV_LINKS_HASH_STRATEGY to 2 or 3 and see
>>>>> if it affects measurably.
>>>>
>>>> Thanks for your quick fixing. I will retest it tomorrow.
>>> Hi, Yura Sokolov
>>> Here is my test result of the v3 patch:
>>> | case | min | avg | max
>>> |
>>> |-------------------------------+------------+------------+------------|
>>> | master (44b61efb79) | 865,743.55 | 871,237.40 | 874,492.59 |
>>> | v3 | 857,020.58 | 860,180.11 | 864,355.00 |
>>> | v3 PREV_LINKS_HASH_STRATEGY=2 | 853,187.41 | 855,796.36 | 858,436.44 |
>>> | v3 PREV_LINKS_HASH_STRATEGY=3 | 863,131.97 | 864,272.91 | 865,396.42 |
>>> It seems there are some performance decreases :( or something I
>>> missed?
>>>
>>
>> Hi, Japin.
>> (Excuse me for duplicating message, I found I sent it only to you
>> first time).
>>
> Never mind!
>
>> v3 (as well as v2) doesn't increase NUM_XLOGINSERT_LOCKS itself.
>> With only 8 in-progress inserters spin-lock is certainly better than any
>> more complex solution.
>>
>> You need to compare "master" vs "master + NUM_XLOGINSERT_LOCKS=64" vs
>> "master + NUM_XLOGINSERT_LOCKS=64 + v3".
>>
>> And even this way I don't claim "Lock-free reservation" gives any profit.
>>
>> That is why your benchmarking is very valuable! It could answer, does
>> we need such not-small patch, or there is no real problem at all?
>>

Hi, Yura Sokolov

Here is the test result compared with NUM_XLOGINSERT_LOCKS and the v3 patch.

| case | min | avg | max | rate% |
|-----------------------+--------------+--------------+--------------+-------|
| master (4108440) | 891,225.77 | 904,868.75 | 913,708.17 | |
| lock 64 | 1,007,716.95 | 1,012,013.22 | 1,018,674.00 | 11.84 |
| lock 64 attempt 1 | 1,016,716.07 | 1,017,735.55 | 1,019,328.36 | 12.47 |
| lock 64 attempt 2 | 1,015,328.31 | 1,018,147.74 | 1,021,513.14 | 12.52 |
| lock 128 | 1,010,147.38 | 1,014,128.11 | 1,018,672.01 | 12.07 |
| lock 128 attempt 1 | 1,018,154.79 | 1,023,348.35 | 1,031,365.42 | 13.09 |
| lock 128 attempt 2 | 1,013,245.56 | 1,018,984.78 | 1,023,696.00 | 12.61 |
| lock 64 v3 | 1,010,893.30 | 1,022,787.25 | 1,029,200.26 | 13.03 |
| lock 64 attempt 1 v3 | 1,014,961.21 | 1,019,745.09 | 1,025,511.62 | 12.70 |
| lock 64 attempt 2 v3 | 1,015,690.73 | 1,018,365.46 | 1,020,200.57 | 12.54 |
| lock 128 v3 | 1,012,653.14 | 1,013,637.09 | 1,014,358.69 | 12.02 |
| lock 128 attempt 1 v3 | 1,008,027.57 | 1,016,849.87 | 1,024,597.15 | 12.38 |
| lock 128 attempt 2 v3 | 1,020,552.04 | 1,024,658.92 | 1,027,855.90 | 13.24 |

--
Regrads,
Japin Li