On 05/08/2017 08:58 AM, Dave Hansen wrote:
It depends on how you define the feature. I think you have three choices:
1. "Error" on page fault. Require all access to be pre-faulted.
2. Allow faults, but "Error" if page cache has to be allocated
3. Allow faults and page cache allocations, but error on filesystem
backing storage allocation.
All of those are useful in some cases. But the implementations probably
happen in different places:
#1 can be implemented in core mm code
#2 can be implemented in the VFS
#3 needs filesystem involvement
Sure it will depend on how we define the feature.
However, I am not clear about how useful are #1 & #2
as a general feature with respect to filesystems, but I
assume we could find some use cases for them.
Regarding #3 as a general feature, do we want to
consider this and the complexity associated with the
implementation?
In case of hugetlbfs it is much straight forward. Since this
filesystem is not like a normal filesystems and and the file sizes
are multiple of huge pages. The hole will be a multiple of the huge
page size. For this reason then should the advise be specific to
hugetlbfs?
Let me paraphrase: it's simpler to implement it if it's specific to
hugetlbfs, thus we should implement it only for hugetlbfs, and keep it
specific to hugetlbfs.
The bigger question is: do we want to continue adding to the complexity
of hugetlbfs and increase its divergence from the core mm?
Ok,
The purpose of hugetlbfs is to enable applications to be
able to use memory in huge page sizes. Expecting that there
will be no change to its purpose other then this. The filesystem
API fallocate(), with the recent addition for hole punching support
to free pages, allows explicit control on page
allocation / deallocation which is useful.
It seems that the 'noautofill' feature is what is missing, with
regards to applications having explicit control on memory page
allocations using hugetlbfs. Even though the description for this
feature is not to fill holes in files, given it is filesystem semantic, but
actually the intent is to indicate not allocating pages implicitly as
the application is primarily dealing with memory allocation and
deallocation here. Is this a good enough justification?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
