Re: [Lse-tech] Re: Hugetlbpages in very large memory machines.......

From: Andy Whitcroft <>
Date: 2004-03-24 04:30:30
Been working on the hugetlb page commitment overcommit issues.  I have
attached a bunch of patches for review purposes, there are a number so I've
not inlined them, but I can send them, just ask.

The first two patches are cosmetic fixes, either in documentation or to
remove a warning later in the game.

010-overcommit_docs:	documentation changes.
015-do_mremap_warning:	change mremap to be more correct and prevents a
warning when later patches are applied.

The next two patches set the scene.  These are the most tested and it is
these that I hope Anton can test for us with his "real world" failure mode.
These two patches introduce the concept of a split between the default and
hugetlb memory pools and stop the hugtlb pool being accounted at all.  This
is not as clean as I would like, particularly the need to check against
VM_AD_DEFAULT in a few places.

050-mem_acctdom_core: core changes to create two accounting domains
055-mem_acctdom_arch: architecture specific changes for above.

The next two patches are work in progress and I present them more for
review of the direction.  This was prompted by the need to check
VM_AD_DEFAULT explicitly to handle vm_committed.  The first splits the
current vm_committed into a per domain count.  The final patch is the
beginnings of making hugetlbfs account for its pages correctly, currently
it actually only exposes the HUGETLB accounting domain.

060-mem_acctdom_commitments: splits vm_committed into a per domain count
070-mem_acctdom_hugetlb: starts the process of using above for hugetlb.

Testing for the first four patches and comments on the direction of the
remaining patches appreciated.


To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at

Received on Tue Mar 23 12:30:03 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:24 EST