Attach to shared memory after fork() - Mailing list pgsql-hackers

From 邱宇航(烛远)
Subject Attach to shared memory after fork()
Date
Msg-id 4684bcc9-b653-4ccc-bbe7-450a602b405c.yuhang.qyh@alibaba-inc.com
Whole thread Raw
Responses Re: Attach to shared memory after fork()
Re: Attach to shared memory after fork()
List pgsql-hackers
Fork is an expensive operation[1]. The major cost is the mm(VMA PTE...) copy.

ARM is especially weak on fork, which will invalid TLB entries one by one, and this is an expensive operation[2]. We could easily got 100% CPU on ARM machine. We also meet fork problem in x86, but not as serious as arm.

We can avoid this by enable hugepage(and 2MB doesn’t help us under arm, we got a huge shared buffer), but we still think it is a problem.

So I propose to remove shared buffers from postmaster and shmat them after fork. Not all of them, we still keep necessary shared memories in postmaster. Or maybe we just need to give up fork like under Windows?

Any good idea about it?

D5.10 TLB maintenance requirements and the TLB maintenance instructions:
Break-before-make sequence on changing from an old translation table entry to a new translation table entryrequires the following steps:
1. Replace the old translation table entry with an invalid entry, and execute a DSB instruction.
2. Invalidate the translation table entry with a broadcast TLB invalidation instruction, and execute a DSBinstruction to ensure the completion of that invalidation.
3. Write the new translation table entry, and execute a DSB instruction to ensure that the new entry is visible.

Regards.
Yuhang Qiu.

pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: logical replication empty transactions
Next
From: Greg Nancarrow
Date:
Subject: Re: [bug?] Missed parallel safety checks, and wrong parallel safety