Re: Large Pages and Super Pages for PostgreSQL

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

In response to

Browse pgsql-hackers by date

  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