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

From: Chen, Kenneth W
Date: Wed Jun 23 2004 - 17:33:44 EST


>>>> Keith Owens wrote on Wednesday, June 23, 2004 3:17 PM
>William Lee Irwin III <wli@xxxxxxxxxxxxxx> 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


-
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/