Skip to content

allow disabling dirty page purging via an API, and consider disabling it by default #18236

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

Closed
thestinger opened this issue Oct 22, 2014 · 4 comments
Labels
A-allocators Area: Custom and system allocators E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@thestinger
Copy link
Contributor

Ratio-based dirty page purging reduces memory usage, but results in a significant performance hit. It is already possible to disable it by exporting an environment variable, but it should be possible to toggle it or alter the ratio at runtime. It may make sense to have it disabled by default because it's not desirable in short-lived applications or those with consistent memory allocation patterns.

It's primarily desirable in large, long-lived applications with varying memory usage patterns where opting into a feature is not a big deal. The defaults should likely be optimized for programming in the small.

@thestinger thestinger added I-slow Issue: Problems and improvements with respect to performance of generated code. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. A-allocators Area: Custom and system allocators labels Oct 22, 2014
@emberian emberian self-assigned this Mar 25, 2015
@emberian emberian removed their assignment Jan 5, 2016
@bstrie
Copy link
Contributor

bstrie commented Jul 14, 2016

Triage: this sounds like something that ought to be relocated to the RFCs repo.

@Mark-Simulacrum
Copy link
Member

I presume this happens today? Could someone confirm that? It seems that this would indeed be better suited to the RFC repo as an issue...

@jonas-schievink
Copy link
Contributor

There is no such API, and I don't think we're doing this automatically. jemalloc(3) indicates that this can be done via a call to mallctl (or, as the OP mentions, by setting the MALLOC_CONF environment variable). After global allocators are stabilized, someone could write a jemalloc crate that provides an API around that. I agree that this should go into the RFC repo, though.

@Mark-Simulacrum
Copy link
Member

Closing. If someone wants to pursue this, please follow the RFC process here https://github.com/rust-lang/rfcs#before-creating-an-rfc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-allocators Area: Custom and system allocators E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

No branches or pull requests

5 participants