You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let me start by thanking you for this contribution which is quite an elegant approach to a common need/use-case.
While considering the potential for production use a few questions arose:
Do you have any plains to submit this for inclusion into the mainline kernel at some point?
Are the allocated pages capable of using other page sizes available to the system without requiring enabling THP or hugetlbfs. Similarly to tmpfs now supports huge=always
Is it possible to bind the pages to NUMA natively? As this involves a kernel module I would expect the support to be a load time option unless the daemon and management tooling being executed using numactl or hwloc-bind would work?
Sincerely,
A fellow chi-town native.
The text was updated successfully, but these errors were encountered:
@CyberTaoFlow Thank you so much for the kind words and for your interest in my project. To answer your questions:
I once tried to submit my code to the mainline kernel but was met with resistance. Not because of the quality but only because maintainers felt that some portions of the logic duplicated what was already part of the kernel and suggested that I take the rest of the code and integrate it into the existing brd module (maybe it was known as rd at the time, I cannot recall ATM).
No. Not at the moment. 4K is the only supported page size.
At the moment, it isn't possible to bind pages to NUMA natively. The module dynamically allocates pages upon request. It is essentially a thinly provisioned drive when created and will only consume the amount of memory when written. Maybe it would be possible to implement such a thing if the memory was preallocated.
To be honest, I have been implementing/maintaining this code since at least 2009 and recent life changes has made it extremely difficult for me to continue maintaining outside of reviewing and merging contributor pull requests. Ideally, if I can find someone or even a company to take over my efforts (and maybe implement some of what you are asking about), that would be phenomenal.
Hello,
Let me start by thanking you for this contribution which is quite an elegant approach to a common need/use-case.
While considering the potential for production use a few questions arose:
Do you have any plains to submit this for inclusion into the mainline kernel at some point?
Are the allocated pages capable of using other page sizes available to the system without requiring enabling THP or hugetlbfs. Similarly to tmpfs now supports huge=always
Is it possible to bind the pages to NUMA natively? As this involves a kernel module I would expect the support to be a load time option unless the daemon and management tooling being executed using numactl or hwloc-bind would work?
Sincerely,
A fellow chi-town native.
The text was updated successfully, but these errors were encountered: