From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx166.postini.com [74.125.245.166]) by kanga.kvack.org (Postfix) with SMTP id CB8826B0005 for ; Tue, 12 Feb 2013 19:51:09 -0500 (EST) Date: Tue, 12 Feb 2013 16:51:07 -0800 From: Andrew Morton Subject: Re: [Bug 53501] New: Duplicated MemTotal with different values Message-Id: <20130212165107.32be0c33.akpm@linux-foundation.org> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: sworddragon2@aol.com Cc: bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Fri, 8 Feb 2013 09:39:27 +0000 (UTC) bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=53501 > > Summary: Duplicated MemTotal with different values > Product: Memory Management > Version: 2.5 > Kernel Version: Ubuntu 3.8.0-4.8-generic 3.8.0-rc6 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: akpm@linux-foundation.org > ReportedBy: sworddragon2@aol.com > Regression: No > > > The installed memory on my system is 16 GiB. /proc/meminfo is showing me > "MemTotal: 16435048 kB" but /sys/devices/system/node/node0/meminfo is > showing me "Node 0 MemTotal: 16776380 kB". > > My suggestion: MemTotal in /proc/meminfo should be 16776380 kB too. The old > value of 16435048 kB could have its own key "MemAvailable". hm, mine does that too. A discrepancy between `totalram_pages' and NODE_DATA(0)->node_present_pages. I don't know what the reasons are for that but yes, one would expect the per-node MemTotals to sum up to the global one. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx133.postini.com [74.125.245.133]) by kanga.kvack.org (Postfix) with SMTP id A25556B0005 for ; Tue, 12 Feb 2013 20:45:45 -0500 (EST) Received: by mail-da0-f48.google.com with SMTP id v40so299432dad.35 for ; Tue, 12 Feb 2013 17:45:44 -0800 (PST) Date: Tue, 12 Feb 2013 17:45:42 -0800 (PST) From: David Rientjes Subject: Re: [Bug 53501] New: Duplicated MemTotal with different values In-Reply-To: <20130212165107.32be0c33.akpm@linux-foundation.org> Message-ID: References: <20130212165107.32be0c33.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: Jiang Liu , sworddragon2@aol.com, bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On Tue, 12 Feb 2013, Andrew Morton wrote: > > Summary: Duplicated MemTotal with different values > > Product: Memory Management > > Version: 2.5 > > Kernel Version: Ubuntu 3.8.0-4.8-generic 3.8.0-rc6 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: Other > > AssignedTo: akpm@linux-foundation.org > > ReportedBy: sworddragon2@aol.com > > Regression: No > > > > > > The installed memory on my system is 16 GiB. /proc/meminfo is showing me > > "MemTotal: 16435048 kB" but /sys/devices/system/node/node0/meminfo is > > showing me "Node 0 MemTotal: 16776380 kB". > > > > My suggestion: MemTotal in /proc/meminfo should be 16776380 kB too. The old > > value of 16435048 kB could have its own key "MemAvailable". > > hm, mine does that too. A discrepancy between `totalram_pages' and > NODE_DATA(0)->node_present_pages. > > I don't know what the reasons are for that but yes, one would expect > the per-node MemTotals to sum up to the global one. > I'd suspect it has something to do with 9feedc9d831e ("mm: introduce new field "managed_pages" to struct zone") and 3.8 would be the first kernel release with this change. Is it possible to try 3.7 or, better yet, with this patch reverted? If neither of these are the case, or you aren't comfortable building and booting a custom kernel, please send along your /proc/zoneinfo. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx165.postini.com [74.125.245.165]) by kanga.kvack.org (Postfix) with SMTP id 5FD716B0005 for ; Tue, 12 Feb 2013 23:00:46 -0500 (EST) Date: Tue, 12 Feb 2013 19:59:29 -0800 From: Andrew Morton Subject: Re: [Bug 53501] New: Duplicated MemTotal with different values Message-Id: <20130212195929.7cd2e597.akpm@linux-foundation.org> In-Reply-To: References: <20130212165107.32be0c33.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: Jiang Liu , sworddragon2@aol.com, bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On Tue, 12 Feb 2013 17:45:42 -0800 (PST) David Rientjes wrote: > > > The installed memory on my system is 16 GiB. /proc/meminfo is showing me > > > "MemTotal: 16435048 kB" but /sys/devices/system/node/node0/meminfo is > > > showing me "Node 0 MemTotal: 16776380 kB". > > > > > > My suggestion: MemTotal in /proc/meminfo should be 16776380 kB too. The old > > > value of 16435048 kB could have its own key "MemAvailable". > > > > hm, mine does that too. A discrepancy between `totalram_pages' and > > NODE_DATA(0)->node_present_pages. > > > > I don't know what the reasons are for that but yes, one would expect > > the per-node MemTotals to sum up to the global one. > > > > I'd suspect it has something to do with 9feedc9d831e ("mm: introduce new > field "managed_pages" to struct zone") and 3.8 would be the first kernel > release with this change. Is it possible to try 3.7 or, better yet, with > this patch reverted? My desktop machine at google in inconsistent, as is the 2.6.32-based machine, so it obviously predates 9feedc9d831e. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx190.postini.com [74.125.245.190]) by kanga.kvack.org (Postfix) with SMTP id F32166B0002 for ; Wed, 13 Feb 2013 22:19:12 -0500 (EST) Received: by mail-da0-f52.google.com with SMTP id f10so840106dak.25 for ; Wed, 13 Feb 2013 19:19:12 -0800 (PST) Date: Wed, 13 Feb 2013 19:19:09 -0800 (PST) From: David Rientjes Subject: Re: [Bug 53501] New: Duplicated MemTotal with different values In-Reply-To: <20130212195929.7cd2e597.akpm@linux-foundation.org> Message-ID: References: <20130212165107.32be0c33.akpm@linux-foundation.org> <20130212195929.7cd2e597.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: Jiang Liu , sworddragon2@aol.com, bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On Tue, 12 Feb 2013, Andrew Morton wrote: > > > > The installed memory on my system is 16 GiB. /proc/meminfo is showing me > > > > "MemTotal: 16435048 kB" but /sys/devices/system/node/node0/meminfo is > > > > showing me "Node 0 MemTotal: 16776380 kB". > > > > > > > > My suggestion: MemTotal in /proc/meminfo should be 16776380 kB too. The old > > > > value of 16435048 kB could have its own key "MemAvailable". > > > > > > hm, mine does that too. A discrepancy between `totalram_pages' and > > > NODE_DATA(0)->node_present_pages. > > > > > > I don't know what the reasons are for that but yes, one would expect > > > the per-node MemTotals to sum up to the global one. > > > > > > > I'd suspect it has something to do with 9feedc9d831e ("mm: introduce new > > field "managed_pages" to struct zone") and 3.8 would be the first kernel > > release with this change. Is it possible to try 3.7 or, better yet, with > > this patch reverted? > > My desktop machine at google in inconsistent, as is the 2.6.32-based > machine, so it obviously predates 9feedc9d831e. > Hmm, ok. The question is which one is right: the per-node MemTotal is the amount of present RAM, the spanned range minus holes, and the system MemTotal is the amount of pages released to the buddy allocator by bootmem and discounts not only the memory holes but also reserved pages. Should they both be the amount of RAM present or the amount of unreserved RAM present? -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx196.postini.com [74.125.245.196]) by kanga.kvack.org (Postfix) with SMTP id 73ED36B0002 for ; Wed, 13 Feb 2013 23:02:00 -0500 (EST) Received: by mail-ia0-f169.google.com with SMTP id j5so1956414iaf.0 for ; Wed, 13 Feb 2013 20:01:59 -0800 (PST) Message-ID: <511C61AD.2010702@gmail.com> Date: Thu, 14 Feb 2013 12:01:49 +0800 From: Jiang Liu MIME-Version: 1.0 Subject: Re: [Bug 53501] New: Duplicated MemTotal with different values References: <20130212165107.32be0c33.akpm@linux-foundation.org> <20130212195929.7cd2e597.akpm@linux-foundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: Andrew Morton , sworddragon2@aol.com, bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On 02/14/2013 11:19 AM, David Rientjes wrote: > On Tue, 12 Feb 2013, Andrew Morton wrote: > >>>>> The installed memory on my system is 16 GiB. /proc/meminfo is showing me >>>>> "MemTotal: 16435048 kB" but /sys/devices/system/node/node0/meminfo is >>>>> showing me "Node 0 MemTotal: 16776380 kB". >>>>> >>>>> My suggestion: MemTotal in /proc/meminfo should be 16776380 kB too. The old >>>>> value of 16435048 kB could have its own key "MemAvailable". >>>> >>>> hm, mine does that too. A discrepancy between `totalram_pages' and >>>> NODE_DATA(0)->node_present_pages. >>>> >>>> I don't know what the reasons are for that but yes, one would expect >>>> the per-node MemTotals to sum up to the global one. >>>> >>> >>> I'd suspect it has something to do with 9feedc9d831e ("mm: introduce new >>> field "managed_pages" to struct zone") and 3.8 would be the first kernel >>> release with this change. Is it possible to try 3.7 or, better yet, with >>> this patch reverted? >> >> My desktop machine at google in inconsistent, as is the 2.6.32-based >> machine, so it obviously predates 9feedc9d831e. >> > > Hmm, ok. The question is which one is right: the per-node MemTotal is the > amount of present RAM, the spanned range minus holes, and the system > MemTotal is the amount of pages released to the buddy allocator by > bootmem and discounts not only the memory holes but also reserved pages. > Should they both be the amount of RAM present or the amount of unreserved > RAM present? > Hi David, We have worked out a patch set to address this issue. The first two patches have been merged into v3.8, and another two patches are queued in Andrew's mm tree for v3.9. The patch set introduces a new field named managed_pages into struct zone to distinguish between pages present in a zone and pages managed by the buddy system. So zone->present_pages = zone->spanned_pages - pages_in_hole; zone->managed_pages = pages_managed_by_buddy_system_in_the_zone; We have also added a field named "managed" into /proc/zoneinfo, but haven't touch /proc/meminfo and /sys/devices/system/node/nodex/meminfo yet. If preferred, we could work out another patch to enhance these two files as suggested above. Regards! Gerry -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx116.postini.com [74.125.245.116]) by kanga.kvack.org (Postfix) with SMTP id C5C8A6B0002 for ; Thu, 14 Feb 2013 19:26:05 -0500 (EST) Received: by mail-da0-f52.google.com with SMTP id f10so1256741dak.39 for ; Thu, 14 Feb 2013 16:26:05 -0800 (PST) Date: Thu, 14 Feb 2013 16:26:03 -0800 (PST) From: David Rientjes Subject: Re: [Bug 53501] New: Duplicated MemTotal with different values In-Reply-To: <511C61AD.2010702@gmail.com> Message-ID: References: <20130212165107.32be0c33.akpm@linux-foundation.org> <20130212195929.7cd2e597.akpm@linux-foundation.org> <511C61AD.2010702@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Jiang Liu Cc: Andrew Morton , sworddragon2@aol.com, bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On Thu, 14 Feb 2013, Jiang Liu wrote: > > Hmm, ok. The question is which one is right: the per-node MemTotal is the > > amount of present RAM, the spanned range minus holes, and the system > > MemTotal is the amount of pages released to the buddy allocator by > > bootmem and discounts not only the memory holes but also reserved pages. > > Should they both be the amount of RAM present or the amount of unreserved > > RAM present? > > > Hi David, > We have worked out a patch set to address this issue. The first two > patches have been merged into v3.8, and another two patches are queued in > Andrew's mm tree for v3.9. > The patch set introduces a new field named managed_pages into struct > zone to distinguish between pages present in a zone and pages managed by the > buddy system. So > zone->present_pages = zone->spanned_pages - pages_in_hole; > zone->managed_pages = pages_managed_by_buddy_system_in_the_zone; > We have also added a field named "managed" into /proc/zoneinfo, but > haven't touch /proc/meminfo and /sys/devices/system/node/nodex/meminfo yet. > If preferred, we could work out another patch to enhance these two files > as suggested above. I'm glad this is a known issue that you're working on, but my question still stands: if MemTotal is going to be consistent throughout /proc/meminfo and /sys/devices/system/node/nodeX/meminfo, which is correct? The present RAM minus holes or the amount available to the buddy allocator not including reserved memory? -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx199.postini.com [74.125.245.199]) by kanga.kvack.org (Postfix) with SMTP id C223B6B00B5 for ; Sat, 16 Feb 2013 11:27:48 -0500 (EST) Received: by mail-pa0-f48.google.com with SMTP id hz10so2188609pad.7 for ; Sat, 16 Feb 2013 08:27:47 -0800 (PST) From: Jiang Liu Subject: [PATCH 1/2] vm: add 'MemManaged' field to /proc/meminfo and /sys/.../nodex/meminfo Date: Sun, 17 Feb 2013 00:27:25 +0800 Message-Id: <1361032046-1725-1-git-send-email-jiang.liu@huawei.com> In-Reply-To: References: Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes , Andrew Morton , sworddragon2@aol.com Cc: Jiang Liu , bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org As reported by https://bugzilla.kernel.org/show_bug.cgi?id=53501, "MemTotal" from /proc/meminfo means memory pages managed by the buddy system (managed_pages), but "MemTotal" from /sys/.../node/nodex/meminfo means phsical pages present (present_pages) within the NUMA node. There's a difference between managed_pages and present_pages due to bootmem allocator and reserved pages. So introduce a new field "MemManaged" to /sys/.../nodex/meminfo and /proc/meminfo, so that: MemTotal = present_pages MemManaged = managed_pages = present_pages - reserved_pages Signed-off-by: Jiang Liu Reported-by: sworddragon2@aol.com --- Hi Andrew and David, How about these draft patches? It just passes compilation. If you are OK with them, we will conduct tests tomorrow. Regards! Gerry --- drivers/base/node.c | 2 ++ fs/proc/meminfo.c | 2 ++ mm/page_alloc.c | 19 ++++++++++++++++++- 3 files changed, 22 insertions(+), 1 deletion(-) diff --git a/drivers/base/node.c b/drivers/base/node.c index fac124a..6508c4d 100644 --- a/drivers/base/node.c +++ b/drivers/base/node.c @@ -66,6 +66,7 @@ static ssize_t node_read_meminfo(struct device *dev, si_meminfo_node(&i, nid); n = sprintf(buf, "Node %d MemTotal: %8lu kB\n" + "Node %d MemManaged: %8lu kB\n" "Node %d MemFree: %8lu kB\n" "Node %d MemUsed: %8lu kB\n" "Node %d Active: %8lu kB\n" @@ -77,6 +78,7 @@ static ssize_t node_read_meminfo(struct device *dev, "Node %d Unevictable: %8lu kB\n" "Node %d Mlocked: %8lu kB\n", nid, K(i.totalram), + nid, K(i.sharedram), nid, K(i.freeram), nid, K(i.totalram - i.freeram), nid, K(node_page_state(nid, NR_ACTIVE_ANON) + diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c index 80e4645..5d58cbb 100644 --- a/fs/proc/meminfo.c +++ b/fs/proc/meminfo.c @@ -54,6 +54,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v) */ seq_printf(m, "MemTotal: %8lu kB\n" + "MemManaged: %8lu kB\n" "MemFree: %8lu kB\n" "Buffers: %8lu kB\n" "Cached: %8lu kB\n" @@ -106,6 +107,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v) #endif , K(i.totalram), + K(totalram_pages), K(i.freeram), K(i.bufferram), K(cached), diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 595e655..6884dc5 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2830,7 +2830,13 @@ static inline void show_node(struct zone *zone) void si_meminfo(struct sysinfo *val) { - val->totalram = totalram_pages; + int nid; + unsigned long present_pages = 0; + + for_each_node_state(nid, N_MEMORY) + present_pages += node_present_pages(nid); + + val->totalram = present_pages; val->sharedram = 0; val->freeram = global_page_state(NR_FREE_PAGES); val->bufferram = nr_blockdev_pages(); @@ -2844,8 +2850,19 @@ EXPORT_SYMBOL(si_meminfo); #ifdef CONFIG_NUMA void si_meminfo_node(struct sysinfo *val, int nid) { + int zone_type; + unsigned long managed_pages = 0; pg_data_t *pgdat = NODE_DATA(nid); + for (zone_type = 0; zone_type < MAX_NR_ZONES; zone_type++) + managed_pages += pgdat->node_zones[zone_type].managed_pages; + + /* + * Ugly hack: struct sysinfo is exported to userspace and there's no + * space available for a new field "managedram", so reuse field + * "sharedram". + */ + val->sharedram = managed_pages; val->totalram = pgdat->node_present_pages; val->freeram = node_page_state(nid, NR_FREE_PAGES); #ifdef CONFIG_HIGHMEM -- 1.7.9.5 -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx192.postini.com [74.125.245.192]) by kanga.kvack.org (Postfix) with SMTP id 6902B6B00B6 for ; Sat, 16 Feb 2013 11:27:52 -0500 (EST) Received: by mail-pb0-f44.google.com with SMTP id wz12so1024750pbc.31 for ; Sat, 16 Feb 2013 08:27:51 -0800 (PST) From: Jiang Liu Subject: [PATCH 2/2] mm: protect si_meminfo() and si_meminfo_node() from memory hotplug operations Date: Sun, 17 Feb 2013 00:27:26 +0800 Message-Id: <1361032046-1725-2-git-send-email-jiang.liu@huawei.com> In-Reply-To: <1361032046-1725-1-git-send-email-jiang.liu@huawei.com> References: <1361032046-1725-1-git-send-email-jiang.liu@huawei.com> In-Reply-To: References: Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes , Andrew Morton , sworddragon2@aol.com Cc: Jiang Liu , bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org There's typical usage of si_meminfo as below: si_meminfo(&si); threshold = si->totalram - si.totalhigh; It may cause underflow if memory hotplug races with si_meminfo() because there's no mechanism to protect si_meminfo() from memory hotplug operations. And some callers expects that si_meminfo() is a lightweight operations. So introduce a lightweight mechanism to protect si_meminfo() from memory hotplug operations. Signed-off-by: Jiang Liu --- mm/page_alloc.c | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6884dc5..5cf03d4 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2831,18 +2831,34 @@ static inline void show_node(struct zone *zone) void si_meminfo(struct sysinfo *val) { int nid; - unsigned long present_pages = 0; + unsigned long present_pages; + val->sharedram = 0; + val->mem_unit = PAGE_SIZE; + +restart: + present_pages = 0; for_each_node_state(nid, N_MEMORY) present_pages += node_present_pages(nid); val->totalram = present_pages; - val->sharedram = 0; val->freeram = global_page_state(NR_FREE_PAGES); val->bufferram = nr_blockdev_pages(); val->totalhigh = totalhigh_pages; val->freehigh = nr_free_highpages(); - val->mem_unit = PAGE_SIZE; + + /* + * si_meminfo() may generate invalid results because it isn't protected + * from memory hotplug operaitons. And some callers expect that it's an + * lightweigh operation. So provide minimal protections without heavy + * overhead. + */ + if (val->totalram < val->freeram || + val->totalram < val->bufferram || + val->totalram < val->totalhigh || + val->totalhigh < val->freehigh || + val->freeram < val->freehigh) + goto restart; } EXPORT_SYMBOL(si_meminfo); @@ -2854,6 +2870,7 @@ void si_meminfo_node(struct sysinfo *val, int nid) unsigned long managed_pages = 0; pg_data_t *pgdat = NODE_DATA(nid); + lock_memory_hotplug(); for (zone_type = 0; zone_type < MAX_NR_ZONES; zone_type++) managed_pages += pgdat->node_zones[zone_type].managed_pages; @@ -2874,6 +2891,7 @@ void si_meminfo_node(struct sysinfo *val, int nid) val->freehigh = 0; #endif val->mem_unit = PAGE_SIZE; + unlock_memory_hotplug(); } #endif -- 1.7.9.5 -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx124.postini.com [74.125.245.124]) by kanga.kvack.org (Postfix) with SMTP id 86B886B0002 for ; Tue, 19 Feb 2013 16:29:55 -0500 (EST) Received: by mail-da0-f51.google.com with SMTP id n15so3154034dad.24 for ; Tue, 19 Feb 2013 13:29:54 -0800 (PST) Date: Tue, 19 Feb 2013 13:29:52 -0800 (PST) From: David Rientjes Subject: Re: [PATCH 1/2] vm: add 'MemManaged' field to /proc/meminfo and /sys/.../nodex/meminfo In-Reply-To: <1361032046-1725-1-git-send-email-jiang.liu@huawei.com> Message-ID: References: <1361032046-1725-1-git-send-email-jiang.liu@huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Jiang Liu Cc: Andrew Morton , sworddragon2@aol.com, Jiang Liu , bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On Sun, 17 Feb 2013, Jiang Liu wrote: > As reported by https://bugzilla.kernel.org/show_bug.cgi?id=53501, > "MemTotal" from /proc/meminfo means memory pages managed by the buddy > system (managed_pages), but "MemTotal" from /sys/.../node/nodex/meminfo > means phsical pages present (present_pages) within the NUMA node. > There's a difference between managed_pages and present_pages due to > bootmem allocator and reserved pages. > > So introduce a new field "MemManaged" to /sys/.../nodex/meminfo and > /proc/meminfo, so that: > MemTotal = present_pages > MemManaged = managed_pages = present_pages - reserved_pages > Nobody is asking for a MemManaged field, we're asking for consistency in MemTotal as exported by /proc/meminfo and /sys/devices/system/node/node*/meminfo. In my opinion, this should be the amount of RAM installed on the system regardless of the amount of memory reserved, i.e. the current /sys/devices/system/node/node*/meminfo semantics. There is no implicit guarantee that memory in MemTotal can be allocated by the buddy allocator. So how about we just make the MemTotal in /proc/meminfo coincide with these semantics? -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx103.postini.com [74.125.245.103]) by kanga.kvack.org (Postfix) with SMTP id 0F8916B0005 for ; Tue, 19 Feb 2013 16:32:25 -0500 (EST) Received: by mail-pb0-f41.google.com with SMTP id um15so2459829pbc.14 for ; Tue, 19 Feb 2013 13:32:25 -0800 (PST) Date: Tue, 19 Feb 2013 13:32:23 -0800 (PST) From: David Rientjes Subject: Re: [PATCH 2/2] mm: protect si_meminfo() and si_meminfo_node() from memory hotplug operations In-Reply-To: <1361032046-1725-2-git-send-email-jiang.liu@huawei.com> Message-ID: References: <1361032046-1725-1-git-send-email-jiang.liu@huawei.com> <1361032046-1725-2-git-send-email-jiang.liu@huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Jiang Liu Cc: Andrew Morton , sworddragon2@aol.com, Jiang Liu , bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On Sun, 17 Feb 2013, Jiang Liu wrote: > There's typical usage of si_meminfo as below: > si_meminfo(&si); > threshold = si->totalram - si.totalhigh; > > It may cause underflow if memory hotplug races with si_meminfo() because > there's no mechanism to protect si_meminfo() from memory hotplug > operations. And some callers expects that si_meminfo() is a lightweight > operations. So introduce a lightweight mechanism to protect si_meminfo() > from memory hotplug operations. > Instead of this, I think it would be appropriate to add a comment that requires synchronization if two fields are going to be compared, i.e. use {lock,unlock}_memory_hotplug() in the caller to si_meminfo(), or appropriate underflow checking is done upon return. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx164.postini.com [74.125.245.164]) by kanga.kvack.org (Postfix) with SMTP id B513C6B0002 for ; Wed, 20 Feb 2013 00:21:19 -0500 (EST) Received: by mail-da0-f47.google.com with SMTP id s35so3335569dak.6 for ; Tue, 19 Feb 2013 21:21:19 -0800 (PST) Message-ID: <51245D48.4030102@gmail.com> Date: Wed, 20 Feb 2013 13:21:12 +0800 From: Simon Jeons MIME-Version: 1.0 Subject: Re: [Bug 53501] New: Duplicated MemTotal with different values References: <20130212165107.32be0c33.akpm@linux-foundation.org> <20130212195929.7cd2e597.akpm@linux-foundation.org> <511C61AD.2010702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: Jiang Liu , Andrew Morton , sworddragon2@aol.com, bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org Hi David, On 02/15/2013 08:26 AM, David Rientjes wrote: > On Thu, 14 Feb 2013, Jiang Liu wrote: > >>> Hmm, ok. The question is which one is right: the per-node MemTotal is the >>> amount of present RAM, the spanned range minus holes, and the system >>> MemTotal is the amount of pages released to the buddy allocator by >>> bootmem and discounts not only the memory holes but also reserved pages. >>> Should they both be the amount of RAM present or the amount of unreserved >>> RAM present? >>> >> Hi David, >> We have worked out a patch set to address this issue. The first two >> patches have been merged into v3.8, and another two patches are queued in >> Andrew's mm tree for v3.9. >> The patch set introduces a new field named managed_pages into struct >> zone to distinguish between pages present in a zone and pages managed by the >> buddy system. So >> zone->present_pages = zone->spanned_pages - pages_in_hole; >> zone->managed_pages = pages_managed_by_buddy_system_in_the_zone; >> We have also added a field named "managed" into /proc/zoneinfo, but >> haven't touch /proc/meminfo and /sys/devices/system/node/nodex/meminfo yet. >> If preferred, we could work out another patch to enhance these two files >> as suggested above. > I'm glad this is a known issue that you're working on, but my question > still stands: if MemTotal is going to be consistent throughout > /proc/meminfo and /sys/devices/system/node/nodeX/meminfo, which is > correct? The present RAM minus holes or the amount available to the buddy > allocator not including reserved memory? What I confuse is why have /proc/meminfo and /proc/vmstat at the same time, they both use to monitor memory subsystem states. What's the root reason? > > -- > 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: email@kvack.org -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx204.postini.com [74.125.245.204]) by kanga.kvack.org (Postfix) with SMTP id AA0A46B0005 for ; Wed, 20 Feb 2013 02:09:49 -0500 (EST) Received: by mail-pa0-f53.google.com with SMTP id bg4so3846121pad.26 for ; Tue, 19 Feb 2013 23:09:48 -0800 (PST) Date: Tue, 19 Feb 2013 23:09:47 -0800 (PST) From: David Rientjes Subject: Re: [Bug 53501] New: Duplicated MemTotal with different values In-Reply-To: <51245D48.4030102@gmail.com> Message-ID: References: <20130212165107.32be0c33.akpm@linux-foundation.org> <20130212195929.7cd2e597.akpm@linux-foundation.org> <511C61AD.2010702@gmail.com> <51245D48.4030102@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Simon Jeons Cc: Jiang Liu , Andrew Morton , sworddragon2@aol.com, bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On Wed, 20 Feb 2013, Simon Jeons wrote: > What I confuse is why have /proc/meminfo and /proc/vmstat at the same time, > they both use to monitor memory subsystem states. What's the root reason? > This has nothing to do with this thread, but /proc/vmstat actually does not include the MemTotal value being discussed in this thread that /proc/meminfo does. /proc/meminfo is typically the interface used by applications, probably mostly for historical purposes since both are present when procfs is configured and mounted, but also to avoid determining the native page size. There's no implicit userspace API exported by /proc/vmstat. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx187.postini.com [74.125.245.187]) by kanga.kvack.org (Postfix) with SMTP id C2BA86B0007 for ; Wed, 20 Feb 2013 12:28:33 -0500 (EST) Received: by mail-pa0-f42.google.com with SMTP id kq12so4153530pab.1 for ; Wed, 20 Feb 2013 09:28:33 -0800 (PST) From: Jiang Liu Subject: [PATCH v2] mm: let /proc/meminfo report physical memory installed as "MemTotal" Date: Thu, 21 Feb 2013 01:27:25 +0800 Message-Id: <1361381245-14664-1-git-send-email-jiang.liu@huawei.com> In-Reply-To: References: Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes , Andrew Morton , sworddragon2@aol.com Cc: Jiang Liu , bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org As reported by https://bugzilla.kernel.org/show_bug.cgi?id=53501, "MemTotal" from /proc/meminfo means memory pages managed by the buddy system (managed_pages), but "MemTotal" from /sys/.../node/nodex/meminfo means phsical pages present (present_pages) within the NUMA node. There's a difference between managed_pages and present_pages due to bootmem allocator and reserved pages. So change /proc/meminfo to report physical memory installed as "MemTotal", which is MemTotal = sum(pgdat->present_pages) Signed-off-by: Jiang Liu Reported-by: sworddragon2@aol.com --- Hi David, How about this simpilified version? Regards! Gerry --- mm/page_alloc.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index e4e8bf1..8e53d6e 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2835,7 +2835,13 @@ static inline void show_node(struct zone *zone) void si_meminfo(struct sysinfo *val) { - val->totalram = totalram_pages; + int nid; + unsigned long present_pages = 0; + + for_each_node_state(nid, N_MEMORY) + present_pages += node_present_pages(nid); + + val->totalram = present_pages; val->sharedram = 0; val->freeram = global_page_state(NR_FREE_PAGES); val->bufferram = nr_blockdev_pages(); -- 1.7.9.5 -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx198.postini.com [74.125.245.198]) by kanga.kvack.org (Postfix) with SMTP id 8ACB26B0022 for ; Wed, 20 Feb 2013 17:49:19 -0500 (EST) Date: Wed, 20 Feb 2013 14:49:17 -0800 From: Andrew Morton Subject: Re: [PATCH v2] mm: let /proc/meminfo report physical memory installed as "MemTotal" Message-Id: <20130220144917.7d289ef0.akpm@linux-foundation.org> In-Reply-To: <1361381245-14664-1-git-send-email-jiang.liu@huawei.com> References: <1361381245-14664-1-git-send-email-jiang.liu@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Jiang Liu Cc: David Rientjes , sworddragon2@aol.com, Jiang Liu , bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On Thu, 21 Feb 2013 01:27:25 +0800 Jiang Liu wrote: > As reported by https://bugzilla.kernel.org/show_bug.cgi?id=53501, > "MemTotal" from /proc/meminfo means memory pages managed by the buddy > system (managed_pages), but "MemTotal" from /sys/.../node/nodex/meminfo > means phsical pages present (present_pages) within the NUMA node. > There's a difference between managed_pages and present_pages due to > bootmem allocator and reserved pages. > > So change /proc/meminfo to report physical memory installed as > "MemTotal", which is > MemTotal = sum(pgdat->present_pages) Documentation/filesystems/proc.txt says MemTotal: Total usable ram (i.e. physical ram minus a few reserved bits and the kernel binary code) And arguably, that is more useful than "total physical memory". Presumably the per-node MemTotals are including kernel memory and reserved memory. Maybe they should be fixed instead (sounds hard). Or maybe we just leave everything as-is and document it carefully. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx191.postini.com [74.125.245.191]) by kanga.kvack.org (Postfix) with SMTP id D11776B0011 for ; Thu, 21 Feb 2013 12:26:40 -0500 (EST) Received: by mail-pa0-f48.google.com with SMTP id hz10so4880390pad.7 for ; Thu, 21 Feb 2013 09:26:40 -0800 (PST) Message-ID: <512658AA.5060806@gmail.com> Date: Fri, 22 Feb 2013 01:26:02 +0800 From: Jiang Liu MIME-Version: 1.0 Subject: Re: [PATCH v2] mm: let /proc/meminfo report physical memory installed as "MemTotal" References: <1361381245-14664-1-git-send-email-jiang.liu@huawei.com> <20130220144917.7d289ef0.akpm@linux-foundation.org> In-Reply-To: <20130220144917.7d289ef0.akpm@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: David Rientjes , sworddragon2@aol.com, Jiang Liu , bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On 02/21/2013 06:49 AM, Andrew Morton wrote: > On Thu, 21 Feb 2013 01:27:25 +0800 > Jiang Liu wrote: > >> As reported by https://bugzilla.kernel.org/show_bug.cgi?id=53501, >> "MemTotal" from /proc/meminfo means memory pages managed by the buddy >> system (managed_pages), but "MemTotal" from /sys/.../node/nodex/meminfo >> means phsical pages present (present_pages) within the NUMA node. >> There's a difference between managed_pages and present_pages due to >> bootmem allocator and reserved pages. >> >> So change /proc/meminfo to report physical memory installed as >> "MemTotal", which is >> MemTotal = sum(pgdat->present_pages) > > Documentation/filesystems/proc.txt says > > MemTotal: Total usable ram (i.e. physical ram minus a few reserved > bits and the kernel binary code) > > And arguably, that is more useful than "total physical memory". > > Presumably the per-node MemTotals are including kernel memory and > reserved memory. Maybe they should be fixed instead (sounds hard). Hi Andrew, It's really hard, but I think it deserve it because have reduced about 460 lines of code when fixing this bug. So how about following patchset? The first 27 patches introduces some help functions to simplify free_initmem() and free_initrd_mem() for most arches. The 28th patch increases zone->managed_pages when freeing reserved pages. The 29th patch change /sys/.../nodex/meminfo to report "available pages within the node" as MemTatoal. Regards! Gerry Jiang Liu (29): mm: introduce free_reserved_mem/page() to reduce duplicated code mm/alpha: use common help functions to free reserved pages mm/ARM: use common help functions to free reserved pages mm/avr32: use common help functions to free reserved pages mm/blackfin: use common help functions to free reserved pages mm/c6x: use common help functions to free reserved pages mm/cris: use common help functions to free reserved pages mm/FRV: use common help functions to free reserved pages mm/h8300: use common help functions to free reserved pages mm/IA64: use common help functions to free reserved pages mm/m32r: use common help functions to free reserved pages mm/m68k: use common help functions to free reserved pages mm/microblaze: use common help functions to free reserved pages mm/MIPS: use common help functions to free reserved pages mm/mn10300: use common help functions to free reserved pages mm/openrisc: use common help functions to free reserved pages mm/parisc: use common help functions to free reserved pages mm/ppc: use common help functions to free reserved pages mm/s390: use common help functions to free reserved pages mm/score: use common help functions to free reserved pages mm/SH: use common help functions to free reserved pages mm/SPARC: use common help functions to free reserved pages mm/um: use common help functions to free reserved pages mm/unicore32: use common help functions to free reserved pages mm/x86: use common help functions to free reserved pages mm/xtensa: use common help functions to free reserved pages mm,kexec: use common help functions to free reserved pages mm: increase zone->managed_pages when freeing reserved pages mm: report available pages as "MemTotal" for each NUMA node arch/alpha/kernel/sys_nautilus.c | 5 ++- arch/alpha/mm/init.c | 21 ++---------- arch/arm/mm/init.c | 43 ++++++++++-------------- arch/arm64/mm/init.c | 26 ++------------- arch/avr32/mm/init.c | 24 ++------------ arch/blackfin/mm/init.c | 20 ++---------- arch/c6x/mm/init.c | 30 ++--------------- arch/cris/mm/init.c | 12 +------ arch/frv/mm/init.c | 26 ++------------- arch/h8300/mm/init.c | 28 ++-------------- arch/ia64/mm/init.c | 23 +++---------- arch/m32r/mm/init.c | 21 ++---------- arch/m68k/mm/init.c | 24 ++------------ arch/microblaze/include/asm/setup.h | 1 - arch/microblaze/mm/init.c | 28 ++-------------- arch/mips/mm/init.c | 13 ++------ arch/mn10300/mm/init.c | 23 ++----------- arch/openrisc/mm/init.c | 23 ++----------- arch/parisc/mm/init.c | 23 ++----------- arch/powerpc/kernel/crash_dump.c | 5 +-- arch/powerpc/kernel/fadump.c | 5 +-- arch/powerpc/kernel/kvm.c | 7 +--- arch/powerpc/mm/mem.c | 29 ++--------------- arch/powerpc/platforms/512x/mpc512x_shared.c | 5 +-- arch/s390/mm/init.c | 23 ++----------- arch/score/mm/init.c | 25 ++------------ arch/sh/mm/init.c | 22 ++----------- arch/sparc/kernel/leon_smp.c | 15 ++------- arch/sparc/mm/init_32.c | 40 ++++------------------- arch/sparc/mm/init_64.c | 20 ++---------- arch/tile/mm/init.c | 1 + arch/um/kernel/mem.c | 10 +----- arch/unicore32/mm/init.c | 26 ++------------- arch/x86/mm/init.c | 5 +-- arch/xtensa/mm/init.c | 21 ++---------- include/linux/mm.h | 45 ++++++++++++++++++++++++++ kernel/kexec.c | 8 ++--- mm/page_alloc.c | 8 ++++- 38 files changed, 139 insertions(+), 595 deletions(-) > > Or maybe we just leave everything as-is and document it carefully. > -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx125.postini.com [74.125.245.125]) by kanga.kvack.org (Postfix) with SMTP id 869346B0002 for ; Thu, 21 Feb 2013 16:31:43 -0500 (EST) Date: Thu, 21 Feb 2013 13:31:41 -0800 From: Andrew Morton Subject: Re: [PATCH v2] mm: let /proc/meminfo report physical memory installed as "MemTotal" Message-Id: <20130221133141.73855348.akpm@linux-foundation.org> In-Reply-To: <512658AA.5060806@gmail.com> References: <1361381245-14664-1-git-send-email-jiang.liu@huawei.com> <20130220144917.7d289ef0.akpm@linux-foundation.org> <512658AA.5060806@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Jiang Liu Cc: David Rientjes , sworddragon2@aol.com, Jiang Liu , bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On Fri, 22 Feb 2013 01:26:02 +0800 Jiang Liu wrote: > It's really hard, but I think it deserve it because have reduced > about 460 lines of code when fixing this bug. So how about following > patchset? > The first 27 patches introduces some help functions to simplify > free_initmem() and free_initrd_mem() for most arches. > The 28th patch increases zone->managed_pages when freeing reserved > pages. > The 29th patch change /sys/.../nodex/meminfo to report "available > pages within the node" as MemTatoal. yikes. Let's defer the problem for now. Please send the patches out in the usual fashion after 3.9-rc1 and we'll take a look? -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx205.postini.com [74.125.245.205]) by kanga.kvack.org (Postfix) with SMTP id 779946B0002 for ; Fri, 22 Feb 2013 14:22:20 -0500 (EST) Received: by mail-pb0-f49.google.com with SMTP id xa12so564830pbc.22 for ; Fri, 22 Feb 2013 11:22:19 -0800 (PST) Message-ID: <5127C55F.1090506@gmail.com> Date: Sat, 23 Feb 2013 03:22:07 +0800 From: Jiang Liu MIME-Version: 1.0 Subject: Re: [PATCH v2] mm: let /proc/meminfo report physical memory installed as "MemTotal" References: <1361381245-14664-1-git-send-email-jiang.liu@huawei.com> <20130220144917.7d289ef0.akpm@linux-foundation.org> <512658AA.5060806@gmail.com> <20130221133141.73855348.akpm@linux-foundation.org> In-Reply-To: <20130221133141.73855348.akpm@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: David Rientjes , sworddragon2@aol.com, Jiang Liu , bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On 02/22/2013 05:31 AM, Andrew Morton wrote: > On Fri, 22 Feb 2013 01:26:02 +0800 > Jiang Liu wrote: > >> It's really hard, but I think it deserve it because have reduced >> about 460 lines of code when fixing this bug. So how about following >> patchset? >> The first 27 patches introduces some help functions to simplify >> free_initmem() and free_initrd_mem() for most arches. >> The 28th patch increases zone->managed_pages when freeing reserved >> pages. >> The 29th patch change /sys/.../nodex/meminfo to report "available >> pages within the node" as MemTatoal. > > yikes. > > Let's defer the problem for now. Please send the patches out in the > usual fashion after 3.9-rc1 and we'll take a look? > Sure, will send out those patches after 3.9-rc1 is out. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx106.postini.com [74.125.245.106]) by kanga.kvack.org (Postfix) with SMTP id 20ABA6B0005 for ; Fri, 1 Mar 2013 21:22:01 -0500 (EST) Received: by mail-oa0-f50.google.com with SMTP id l20so6642066oag.23 for ; Fri, 01 Mar 2013 18:22:00 -0800 (PST) Message-ID: <51316242.1010206@gmail.com> Date: Sat, 02 Mar 2013 10:21:54 +0800 From: Simon Jeons MIME-Version: 1.0 Subject: Re: [Bug 53501] New: Duplicated MemTotal with different values References: <20130212165107.32be0c33.akpm@linux-foundation.org> <20130212195929.7cd2e597.akpm@linux-foundation.org> <511C61AD.2010702@gmail.com> <51245D48.4030102@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: Jiang Liu , Andrew Morton , sworddragon2@aol.com, bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On 02/20/2013 03:09 PM, David Rientjes wrote: > On Wed, 20 Feb 2013, Simon Jeons wrote: > >> What I confuse is why have /proc/meminfo and /proc/vmstat at the same time, >> they both use to monitor memory subsystem states. What's the root reason? >> > This has nothing to do with this thread, but /proc/vmstat actually does > not include the MemTotal value being discussed in this thread that > /proc/meminfo does. /proc/meminfo is typically the interface used by > applications, probably mostly for historical purposes since both are Do you mean /proc/vmstat is not used by applications. sar -B 1 pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff I think they are read from /proc/vmstat > present when procfs is configured and mounted, but also to avoid > determining the native page size. There's no implicit userspace API > exported by /proc/vmstat. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx167.postini.com [74.125.245.167]) by kanga.kvack.org (Postfix) with SMTP id 4BBC26B0006 for ; Mon, 4 Mar 2013 06:18:21 -0500 (EST) Received: by mail-pa0-f42.google.com with SMTP id kq12so3111011pab.15 for ; Mon, 04 Mar 2013 03:18:20 -0800 (PST) Date: Mon, 4 Mar 2013 03:18:18 -0800 (PST) From: David Rientjes Subject: Re: [Bug 53501] New: Duplicated MemTotal with different values In-Reply-To: <51316242.1010206@gmail.com> Message-ID: References: <20130212165107.32be0c33.akpm@linux-foundation.org> <20130212195929.7cd2e597.akpm@linux-foundation.org> <511C61AD.2010702@gmail.com> <51245D48.4030102@gmail.com> <51316242.1010206@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Simon Jeons Cc: Jiang Liu , Andrew Morton , sworddragon2@aol.com, bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On Sat, 2 Mar 2013, Simon Jeons wrote: > > This has nothing to do with this thread, but /proc/vmstat actually does > > not include the MemTotal value being discussed in this thread that > > /proc/meminfo does. /proc/meminfo is typically the interface used by > > applications, probably mostly for historical purposes since both are > > Do you mean /proc/vmstat is not used by applications. > sar -B 1 > pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s > %vmeff > I think they are read from /proc/vmstat > Yes, there is userspace code that parses /proc/vmstat. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx122.postini.com [74.125.245.122]) by kanga.kvack.org (Postfix) with SMTP id 773DC6B0002 for ; Mon, 4 Mar 2013 18:39:37 -0500 (EST) Received: by mail-pb0-f54.google.com with SMTP id rr4so3575021pbb.13 for ; Mon, 04 Mar 2013 15:39:36 -0800 (PST) Message-ID: <513530B1.8050106@gmail.com> Date: Tue, 05 Mar 2013 07:39:29 +0800 From: Simon Jeons MIME-Version: 1.0 Subject: Re: [Bug 53501] New: Duplicated MemTotal with different values References: <20130212165107.32be0c33.akpm@linux-foundation.org> <20130212195929.7cd2e597.akpm@linux-foundation.org> <511C61AD.2010702@gmail.com> <51245D48.4030102@gmail.com> <51316242.1010206@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: Jiang Liu , Andrew Morton , sworddragon2@aol.com, bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On 03/04/2013 07:18 PM, David Rientjes wrote: > On Sat, 2 Mar 2013, Simon Jeons wrote: > >>> This has nothing to do with this thread, but /proc/vmstat actually does >>> not include the MemTotal value being discussed in this thread that >>> /proc/meminfo does. /proc/meminfo is typically the interface used by >>> applications, probably mostly for historical purposes since both are >> Do you mean /proc/vmstat is not used by applications. >> sar -B 1 >> pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s >> %vmeff >> I think they are read from /proc/vmstat >> > Yes, there is userspace code that parses /proc/vmstat. Then why both need /proc/meminfo and /proc/vmstat? -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx112.postini.com [74.125.245.112]) by kanga.kvack.org (Postfix) with SMTP id BD8C16B0002 for ; Tue, 5 Mar 2013 16:53:05 -0500 (EST) Received: by mail-pb0-f44.google.com with SMTP id wz12so5061657pbc.3 for ; Tue, 05 Mar 2013 13:53:05 -0800 (PST) Date: Tue, 5 Mar 2013 13:53:02 -0800 (PST) From: David Rientjes Subject: Re: [Bug 53501] New: Duplicated MemTotal with different values In-Reply-To: <513530B1.8050106@gmail.com> Message-ID: References: <20130212165107.32be0c33.akpm@linux-foundation.org> <20130212195929.7cd2e597.akpm@linux-foundation.org> <511C61AD.2010702@gmail.com> <51245D48.4030102@gmail.com> <51316242.1010206@gmail.com> <513530B1.8050106@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Simon Jeons Cc: Jiang Liu , Andrew Morton , sworddragon2@aol.com, bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org On Tue, 5 Mar 2013, Simon Jeons wrote: > Then why both need /proc/meminfo and /proc/vmstat? > Because we do not break userspace. -- 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: email@kvack.org