Messages in this thread | | | From | "Chen, Kenneth W" <> | Subject | RE: More bug fix in mm/hugetlb.c - fix try_to_free_low() | Date | Wed, 23 Jun 2004 15:24:29 -0700 |
| |
>>>> 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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |