RE: More bug fix in mm/hugetlb.c - fix try_to_free_low()

["Chen, Kenneth W" <kenneth.w.chen@intel.com>]

>>>> Keith Owens wrote on Wednesday, June 23, 2004 3:17 PM
>William Lee Irwin III <wli@holomorphy.com> wrote:
>>On Wed, Jun 23, 2004 at 12:33:00PM -0700, Chen, Kenneth W wrote:
>>> The argument "count" passed to try_to_free_low() is the config parameter
>>> for desired hugetlb page pool size.  But the implementation took that
>>> input argument as number of pages to free. It also decrement the config
>>> parameter as well.  All give random behavior depend on how many hugetlb
>>> pages are in normal/highmem zone.
>>> A two line fix in try_to_free_low() would be:
>>
>>Thanks for cleaning this up; there hasn't been much apparent interest
>>here lately so I've not gotten much in the way of bugreports to work.
>
>While we are discussing hugetlb, what is the official method of
>identifying a hugetlb page - at the page level, not through a vma?
>
>When taking a crash dump, hugetlb pages must be treated as user data,
>not as kernel pages.  LKCD must be able to identify hugetlb pages from
>the page struct, dumping cannot assume that any mm context is valid so
>vma scans are out.  The identification method must work whether the
>hugetlb pages are in use or not.  In 2.4 LKCD I added PG_hugetlb, but I
>would prefer a test that did not require yet another PG flag.

There is one flag already in the page structure: PG_compound.

- Ken