|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>|
|Subject:||Re: Large Pages and Super Pages for PostgreSQL|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Thank you very much for the work.
I just got latest FreeBSD 13.1 environment, and I'm going to test and
so would you please rebase latest patch?
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.
> 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.
|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|