[RFC] Consolidate lots of hugepage code
William Lee Irwin III
wli at holomorphy.com
Mon Nov 8 06:20:24 EST 2004
At some point in the past, I wrote:
>> Further consolidation is premature given that outstanding hugetlb bugs
>> have the implication that architectures' needs are not being served by
>> the current arch/core split. I have at least two relatively major hugetlb
>> bugs outstanding, the lack of a flush_dcache_page() analogue first, and
>> another (soon to be a reported to affected distros) less well-understood.
>> Unless they're directly toward the end of restoring hugetlb to a sound
>> state, they're counterproductive to merge before patches doing so.
On Mon, Nov 08, 2004 at 04:20:30AM +1100, Anton Blanchard wrote:
> Could you point me at a summary of these 2 issues?
It's all pretty obvious. The first is checking page size vs. cache size
and whether it's VI or does anything unusual; thus far things look
hopeful that flush_dcache_page() analogues are unnecessary. More
information about Super-H is needed to wrap up what will probably be no
more than an audit. The second is a triplefault on x86-64 under some
condition involving a long-running database regression test. There has
obviously been considerably less progress there in no small part due to
the amount of time required to reproduce the issue.
More information about the Linuxppc64-dev