Dne Po 20. srpna 2012 08:38:10 wujianguo napsal(a): > From: Jianguo Wu <wujianguo@xxxxxxxxxx> > > Hi all, > I think zone->present_pages indicates pages that buddy system can > management, it should be: > zone->present_pages = spanned pages - absent pages - bootmem pages, > but now: > zone->present_pages = spanned pages - absent pages - memmap pages. > spanned pages：total size, including holes. > absent pages: holes. > bootmem pages: pages used in system boot, managed by bootmem allocator. > memmap pages: pages used by page structs. Absolutely. The memory allocated to page structs should be counted in. > This may cause zone->present_pages less than it should be. > For example, numa node 1 has ZONE_NORMAL and ZONE_MOVABLE, > it's memmap and other bootmem will be allocated from ZONE_MOVABLE, > so ZONE_NORMAL's present_pages should be spanned pages - absent pages, > but now it also minus memmap pages(free_area_init_core), which are actually > allocated from ZONE_MOVABLE. When offline all memory of a zone, This will > cause zone->present_pages less than 0, because present_pages is unsigned > long type, it is actually a very large integer, it indirectly caused > zone->watermark[WMARK_MIN] become a large > integer(setup_per_zone_wmarks()), than cause totalreserve_pages become a > large integer(calculate_totalreserve_pages()), and finally cause memory > allocating failure when fork process(__vm_enough_memory()). > > [root@localhost ~]# dmesg > -bash: fork: Cannot allocate memory > > I think bug described in http://marc.info/?l=linux-mm&m=134502182714186&w=2 > is also caused by wrong zone present pages. And yes, I can confirm that the bug I reported is caused by a too low number for the present pages counter. Your patch does fix the bug for me. Thanks! Petr Tesarik -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href