Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

large page support on windows? #14

Closed
pongba opened this issue Jun 22, 2019 · 4 comments
Closed

large page support on windows? #14

pongba opened this issue Jun 22, 2019 · 4 comments

Comments

@pongba
Copy link

pongba commented Jun 22, 2019

It appears that there's no option to turn on large page support on windows?

Searched the code base, VirtualAlloc was called without MEM_LARGE_PAGES.

Any future plan to support it? It was said to significantly reduce TLB misses and may lead to notable gains in memory intensive scenarios.

@daanx
Copy link
Collaborator

daanx commented Jun 23, 2019

I didn't look into this before but it seems easy to support this on Windows -- I can definitely make this a build variant for you to test :-) However, it would preclude the guard pages in the secure mode.

@mjsabby
Copy link

mjsabby commented Jun 23, 2019

It's best to surface this as an option to the consumer, since Windows, Linux and macOS can all support Large Pages.

A build variant seems less ideal.

@daanx
Copy link
Collaborator

daanx commented Jun 29, 2019

I pushed initial support for large pages on Windows on the dev branch. It is enabled when setting the environment variable MIMALLOC_LARGE_OS_PAGES=1. (note that the "Lock Pages in memory" privilege must be enabled for the user account for it to work).

@daanx daanx closed this as completed Jul 4, 2019
@4cad
Copy link

4cad commented Jul 23, 2019

Just a heads up to be wary when using large pages to folks looking to use this feature, performance boost can be significant but large pages cannot be paged to disk so it essentially grabs physical memory and is trickier to manage.

Implication 1) If you allocate too many large pages you it ends up starving the system of physical memory including the OS, and I have had many a machines lock up completely and become unresponsive under high memory pressure - it is one of those rare bugs that takes down the whole system, and not just the process. We dealt with it by falling back to regular pages after some threshold % of physical memory was given to large pages, so that at least the OS always had memory to work with.

Implication 2) In order for the OS to allocate a large page, it needs to have a full contiguous block of physical memory equal to the size of the large block. I do not know what this entails, but when the system is saturated it can presumably involve de-fragmenting memory or just failing. We had to add a fall-back to handle the case where if a large page allocation fails, we retry with normal pages to handle this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants