[lkml]   [2004]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: More bug fix in mm/hugetlb.c - fix try_to_free_low()
>>>> Keith Owens wrote on Wednesday, June 23, 2004 3:17 PM
>William Lee Irwin III <> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:04    [from the cache]
©2003-2011 Jasper Spaans