From: wujianguo <wujianguo106@gmail.com>
To: Petr Tesarik <ptesarik@suse.cz>
Cc: tony.luck@intel.com, fenghua.yu@intel.com, dhowells@redhat.com,
tj@kernel.org, mgorman@suse.de, yinghai@kernel.org,
minchan.kim@gmail.com, akpm@linux-foundation.org,
viro@zeniv.linux.org.uk, aarcange@redhat.com,
davem@davemloft.net, hannes@cmpxchg.org, liuj97@gmail.com,
wency@cn.fujitsu.com, rientjes@google.com,
kamezawa.hiroyu@jp.fujitsu.com, mhocko@suse.cz,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, jiang.liu@huawei.com, guohanjun@huawei.com,
qiuxishi@huawei.com
Subject: Re: [PATCH]mm: fix-up zone present pages
Date: Fri, 24 Aug 2012 02:31:15 +0000 [thread overview]
Message-ID: <5036E773.6020609@gmail.com> (raw)
In-Reply-To: <201208210555.41312.ptesarik@suse.cz>
On 2012-8-21 11:55, Petr Tesarik wrote:
> Dne Po 20. srpna 2012 08:38:10 wujianguo napsal(a):
>> From: Jianguo Wu <wujianguo@huawei.com>
>>
>> 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.
>
Hi Petr,
Bootmem pages include the memory allocated to page structs.
Thanks!
Jianguo Wu
>> 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\x134502182714186&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
>
WARNING: multiple messages have this Message-ID (diff)
From: wujianguo <wujianguo106@gmail.com>
To: Petr Tesarik <ptesarik@suse.cz>
Cc: tony.luck@intel.com, fenghua.yu@intel.com, dhowells@redhat.com,
tj@kernel.org, mgorman@suse.de, yinghai@kernel.org,
minchan.kim@gmail.com, akpm@linux-foundation.org,
viro@zeniv.linux.org.uk, aarcange@redhat.com,
davem@davemloft.net, hannes@cmpxchg.org, liuj97@gmail.com,
wency@cn.fujitsu.com, rientjes@google.com,
kamezawa.hiroyu@jp.fujitsu.com, mhocko@suse.cz,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, jiang.liu@huawei.com, guohanjun@huawei.com,
qiuxishi@huawei.com
Subject: Re: [PATCH]mm: fix-up zone present pages
Date: Fri, 24 Aug 2012 10:31:15 +0800 [thread overview]
Message-ID: <5036E773.6020609@gmail.com> (raw)
In-Reply-To: <201208210555.41312.ptesarik@suse.cz>
On 2012-8-21 11:55, Petr Tesarik wrote:
> Dne Po 20. srpna 2012 08:38:10 wujianguo napsal(a):
>> From: Jianguo Wu <wujianguo@huawei.com>
>>
>> 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 pagesi 1/4 ?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.
>
Hi Petr,
Bootmem pages include the memory allocated to page structs.
Thanks!
Jianguo Wu
>> 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@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: wujianguo <wujianguo106@gmail.com>
To: Petr Tesarik <ptesarik@suse.cz>
Cc: tony.luck@intel.com, fenghua.yu@intel.com, dhowells@redhat.com,
tj@kernel.org, mgorman@suse.de, yinghai@kernel.org,
minchan.kim@gmail.com, akpm@linux-foundation.org,
viro@zeniv.linux.org.uk, aarcange@redhat.com,
davem@davemloft.net, hannes@cmpxchg.org, liuj97@gmail.com,
wency@cn.fujitsu.com, rientjes@google.com,
kamezawa.hiroyu@jp.fujitsu.com, mhocko@suse.cz,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, jiang.liu@huawei.com, guohanjun@huawei.com,
qiuxishi@huawei.com
Subject: Re: [PATCH]mm: fix-up zone present pages
Date: Fri, 24 Aug 2012 10:31:15 +0800 [thread overview]
Message-ID: <5036E773.6020609@gmail.com> (raw)
In-Reply-To: <201208210555.41312.ptesarik@suse.cz>
On 2012-8-21 11:55, Petr Tesarik wrote:
> Dne Po 20. srpna 2012 08:38:10 wujianguo napsal(a):
>> From: Jianguo Wu <wujianguo@huawei.com>
>>
>> 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.
>
Hi Petr,
Bootmem pages include the memory allocated to page structs.
Thanks!
Jianguo Wu
>> 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
>
next prev parent reply other threads:[~2012-08-24 2:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-20 6:38 [PATCH]mm: fix-up zone present pages wujianguo
2012-08-20 6:38 ` wujianguo
2012-08-20 6:38 ` wujianguo
2012-08-21 3:55 ` Petr Tesarik
2012-08-21 3:55 ` Petr Tesarik
2012-08-21 3:55 ` Petr Tesarik
2012-08-24 2:31 ` wujianguo [this message]
2012-08-24 2:31 ` wujianguo
2012-08-24 2:31 ` wujianguo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5036E773.6020609@gmail.com \
--to=wujianguo106@gmail.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=fenghua.yu@intel.com \
--cc=guohanjun@huawei.com \
--cc=hannes@cmpxchg.org \
--cc=jiang.liu@huawei.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuj97@gmail.com \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=minchan.kim@gmail.com \
--cc=ptesarik@suse.cz \
--cc=qiuxishi@huawei.com \
--cc=rientjes@google.com \
--cc=tj@kernel.org \
--cc=tony.luck@intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=wency@cn.fujitsu.com \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.