I think we don't need this. We have a pblock cleanup underway, and we can just use transparent huge pages.

How does pblock cleanup relate to and invalidate huge page investigation?

First, we have transparent huge pages. We don't need to do this. This is micro optimising for a ghost issue.

Second, the pblock cleanup is that we literally waste 90% of the memory of every pblock we allocate. That's ~630 bytes out of 712 is NULL, every single allocation. We allocate so many pblocks through out the code base, that of course we see terrible memory behaviour.

How about instead of pointing fingers at glib, or hoping for an outside solution like THP, we start to clean up our own mistakes.

In one benchmark I took, reducing the "malloc" size by half, reduced program run time by half, and maximum memory use too. Maybe, once we clean up the pblock, we wont need THP, because we won't be so memory hungry.

Ok, I didn't realize that huge table pages was a non issue for 389, and that you had already done all of the relevant investigation.

As far as other malloc/memory/pblock issues being more important, sure, I'm sure there are, but that means we have to close all other issues that might be too distracting? We can't simply prioritize issues?

That's the thing, we have transparent huge pages now, we shouldn't need to "do anything" to take advantage of them. They "just work".

I think that this issue for example is not required to be open, because of the above, but also that it's been open for 3 years, no one has acted on it, and our current working plan is going in another direction.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/672

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.