[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.

-- wli

More information about the Linuxppc64-dev mailing list