Attach to shared memory after fork()

Поиск
Список
Период
Сортировка
От 邱宇航(烛远)
Тема Attach to shared memory after fork()
Дата
Msg-id 4684bcc9-b653-4ccc-bbe7-450a602b405c.yuhang.qyh@alibaba-inc.com
обсуждение исходный текст
Ответы Re: Attach to shared memory after fork()  (Andrew Dunstan <andrew@dunslane.net>)
Re: Attach to shared memory after fork()  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Ajin Cherian
Дата:
Сообщение: Re: logical replication empty transactions
Следующее
От: Greg Nancarrow
Дата:
Сообщение: Re: [bug?] Missed parallel safety checks, and wrong parallel safety