RE: FW: [PATCH 0/3] Demand faulting for huge pages
From: Chen, Kenneth W
Date: Mon Oct 10 2005 - 01:54:37 EST
Hugh Dickins wrote on Sunday, October 09, 2005 5:27 AM
> We all seem
> to have different agendas for hugetlb. I'm interested in fixing the
> existing bugs with truncation (see -mm), and getting the locking to
> fit with my page_table_lock patches. Prohibiting truncation is an
> attractively easy and efficient way of fixing several such problems.
> Adam is interested in fault on demand, which needs further work if
> truncation is allowed. You and Rohit are interested in enhancing
> the generality of hugetlbfs.
IMO, these three things are not contradictory with each other. They
are orthogonal. Even though maybe we are all touching same lines of
code, in the end, everyone is working toward better and more robust
Demand paging is one aspect of enhancing generality of hugetlb. Intel
initially proposed the feature 18 month ago [* see link below] along
with SGI. Christoph Lameter at SGI scratched that subject Oct 2004.
And now, Adam at IBM attempts it again. There is a growing need to
make hugetlb easier to use, more transparency in using hugetlb pages
etc. All requires hugetlb code to be more generalized, instead of
Granted, the patch I posted on expanding ftruncate will be replaced
once demand paging goes in. I wanted to demonstrate that it is a
feature we should implement, instead of cutting back more on current
thin functionality in hugetlbfs. (with demand paging, expanding
ftruncate should be really easy and clean, instead of "peculiar
semantics" all because of prefaulting).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/