Re: Large Pages and Super Pages for PostgreSQL
| От | Thomas Munro |
|---|---|
| Тема | Re: Large Pages and Super Pages for PostgreSQL |
| Дата | |
| Msg-id | CA+hUKGLmBWHF6gusP55R7jVS1=6T=GphbZpUXiOgMMHDUkVCgw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Large Pages and Super Pages for PostgreSQL (Thomas Munro <thomas.munro@gmail.com>) |
| Ответы |
Re: Large Pages and Super Pages for PostgreSQL
|
| Список | pgsql-hackers |
On Sun, Jan 16, 2022 at 8:32 PM Thomas Munro <thomas.munro@gmail.com> wrote: > On Sun, Jan 16, 2022 at 6:03 PM DEVOPS_WwIT <devops@ww-it.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.
Вложения
В списке pgsql-hackers по дате отправления: