From: | ZHU XIAN WEN <tony(dot)zhu(at)ww-it(dot)cn> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, DEVOPS_WwIT <devops(at)ww-it(dot)cn> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Large Pages and Super Pages for PostgreSQL |
Date: | 2022-11-30 07:29:14 |
Message-ID: | 4b54fa6d-92b0-f7b8-122c-de5f6b861389@ww-it.cn |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Thomas
Thank you very much for the work.
I just got latest FreeBSD 13.1 environment, and I'm going to test and
verify it.
so would you please rebase latest patch?
best wishes
Tony
On 2022/11/8 06:59, Thomas Munro wrote:
> On Sun, Jan 16, 2022 at 8:32 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>> On Sun, Jan 16, 2022 at 6:03 PM DEVOPS_WwIT <devops(at)ww-it(dot)cn> wrote:
>>> Solaris and FreeBSD supports large/super pages, and can be used
>>> automatically by applications.
>>>
>>> Seems Postgres can't use the large/super pages on Solaris and FreeBSD
>>> os(I think can't use the large/super page HPUX and AIX), is there anyone
>>> could take a look?
>> 3. FreeBSD: FreeBSD does transparently migrate PostgreSQL memory to
>> "super" pages quite well in my experience, but there is also a new
>> facility in FreeBSD 13 to ask for specific page sizes explicitly. I
>> wrote a quick and dirty patch to enable PostgreSQL's huge_pages and
>> huge_page_size settings to work with that interface, but I haven't yet
>> got as far as testing it very hard or proposing it... but here it is,
>> if you like experimental code[2].
> I was reminded to rebase that and tidy it up a bit, by recent
> discussion of page table magic in other threads. Documentation of
> these interfaces is sparse to put it mildly (I may try to improve that
> myself) but basically the terminology is "super" for pages subject to
> promotion/demotion, and "large" when explicitly managed. Not
> proposing for commit right now as I need to learn more about all this
> and there are some policy decisions lurking in here (eg synchronous
> defrag vs nowait depending on flags), but the patch may be useful for
> experimentation. For example, it allows huge_page_size=1GB if your
> system can handle that.
Attachment | Content-Type | Size |
---|---|---|
OpenPGP_0x6A40B0F18DBF5A23.asc | application/pgp-keys | 3.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2022-11-30 07:30:15 | Re: [PoC] Improve dead tuple storage for lazy vacuum |
Previous Message | Masahiko Sawada | 2022-11-30 07:27:59 | Re: [PoC] Improve dead tuple storage for lazy vacuum |