Re: patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree

Re: patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree

[Greg KH]

On Tue, May 05, 2009 at 08:36:19PM +0200, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On Dienstag, 5. Mai 2009, gregkh@suse.de wrote:
> [...]
> > From 00a62ce91e554198ef28234c91c36f850f5a3bc9 Mon Sep 17 00:00:00 2001
> > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > Date: Thu, 30 Apr 2009 15:08:51 -0700
> > Subject: mm: fix Committed_AS underflow on large NR_CPUS environment
> > 
> > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > 
> > commit 00a62ce91e554198ef28234c91c36f850f5a3bc9 upstream.
> > 
> > The Committed_AS field can underflow in certain situations:
> > 
> > >         # while true; do cat /proc/meminfo  | grep _AS; sleep 1; done | uniq -c
> > >               1 Committed_AS: 18446744073709323392 kB
> > >              11 Committed_AS: 18446744073709455488 kB
> > >               6 Committed_AS:    35136 kB
> > >               5 Committed_AS: 18446744073709454400 kB
> > >               7 Committed_AS:    35904 kB
> > >               3 Committed_AS: 18446744073709453248 kB
> > >               2 Committed_AS:    34752 kB
> > >               9 Committed_AS: 18446744073709453248 kB
> > >               8 Committed_AS:    34752 kB
> > >               3 Committed_AS: 18446744073709320960 kB
> > >               7 Committed_AS: 18446744073709454080 kB
> > >               3 Committed_AS: 18446744073709320960 kB
> > >               5 Committed_AS: 18446744073709454080 kB
> > >               6 Committed_AS: 18446744073709320960 kB
> > 
> > Because NR_CPUS can be greater than 1000 and meminfo_proc_show() does
> > not check for underflow.
> > 
> > But NR_CPUS proportional isn't good calculation.  In general,
> > possibility of lock contention is proportional to the number of online
> > cpus, not theorical maximum cpus (NR_CPUS).
> > 
> > The current kernel has generic percpu-counter stuff.  using it is right
> > way.  it makes code simplify and percpu_counter_read_positive() don't
> > make underflow issue.
> 
> This patch reproducably panics on all systems I could test so far on 
> 2.6.29.2 + the current stable queue:
> - Acer Aspire One, Intel Atom N270, Intel 945GC chipset (i386)
> - AMD64 3200+, nVidia nforce3 chipset (amd64)
> - AMD64 X2 4200+, nVidia nforce4 chipset (amd64)
> 
> Kernel panic (sorry, this is from a bad webcam and only the last part of 
> the messages scrolling by - I can try to get a serial console tomorrow), 
> taken from an AMD64 3200+, nVidia nforce3 chipset (amd64).
> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/panic.gif [198 KB]
> 
> Reverting just this patch fixes the problem for me.
> 
> Kernel configurations:
> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/config-2.6.29-2.slh.5.3-sidux-686   [96 KB]
> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/config-2.6.29-2.slh.5.6-sidux-amd64 [91 KB]


Thanks for the report, I'm also getting some oopses on boot and am
bisecting down the tree right now.  The error looks a bit like yours,
but not identical enough for me to declare that it is the same thing
just yet.

Give me a few more hours...

thanks,

greg k-h

Re: patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree

[Greg KH]

On Tue, May 05, 2009 at 08:36:19PM +0200, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On Dienstag, 5. Mai 2009, gregkh@suse.de wrote:
> [...]
> > From 00a62ce91e554198ef28234c91c36f850f5a3bc9 Mon Sep 17 00:00:00 2001
> > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > Date: Thu, 30 Apr 2009 15:08:51 -0700
> > Subject: mm: fix Committed_AS underflow on large NR_CPUS environment
> > 
> > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > 
> > commit 00a62ce91e554198ef28234c91c36f850f5a3bc9 upstream.
> > 
> > The Committed_AS field can underflow in certain situations:
> > 
> > >         # while true; do cat /proc/meminfo  | grep _AS; sleep 1; done | uniq -c
> > >               1 Committed_AS: 18446744073709323392 kB
> > >              11 Committed_AS: 18446744073709455488 kB
> > >               6 Committed_AS:    35136 kB
> > >               5 Committed_AS: 18446744073709454400 kB
> > >               7 Committed_AS:    35904 kB
> > >               3 Committed_AS: 18446744073709453248 kB
> > >               2 Committed_AS:    34752 kB
> > >               9 Committed_AS: 18446744073709453248 kB
> > >               8 Committed_AS:    34752 kB
> > >               3 Committed_AS: 18446744073709320960 kB
> > >               7 Committed_AS: 18446744073709454080 kB
> > >               3 Committed_AS: 18446744073709320960 kB
> > >               5 Committed_AS: 18446744073709454080 kB
> > >               6 Committed_AS: 18446744073709320960 kB
> > 
> > Because NR_CPUS can be greater than 1000 and meminfo_proc_show() does
> > not check for underflow.
> > 
> > But NR_CPUS proportional isn't good calculation.  In general,
> > possibility of lock contention is proportional to the number of online
> > cpus, not theorical maximum cpus (NR_CPUS).
> > 
> > The current kernel has generic percpu-counter stuff.  using it is right
> > way.  it makes code simplify and percpu_counter_read_positive() don't
> > make underflow issue.
> 
> This patch reproducably panics on all systems I could test so far on 
> 2.6.29.2 + the current stable queue:
> - Acer Aspire One, Intel Atom N270, Intel 945GC chipset (i386)
> - AMD64 3200+, nVidia nforce3 chipset (amd64)
> - AMD64 X2 4200+, nVidia nforce4 chipset (amd64)
> 
> Kernel panic (sorry, this is from a bad webcam and only the last part of 
> the messages scrolling by - I can try to get a serial console tomorrow), 
> taken from an AMD64 3200+, nVidia nforce3 chipset (amd64).
> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/panic.gif [198 KB]
> 
> Reverting just this patch fixes the problem for me.
> 
> Kernel configurations:
> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/config-2.6.29-2.slh.5.3-sidux-686   [96 KB]
> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/config-2.6.29-2.slh.5.6-sidux-amd64 [91 KB]

Yes, I just confirmed this on my machines as well, so I'm going to drop
it from the stable queue.

If anyone thinks it is really necessary for the 2.6.29-stable tree,
please resubmit it after fixing it and testing that it works :)

thanks,

greg k-h

Re: patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree

[KOSAKI Motohiro]

2009/5/6 Greg KH <gregkh@suse.de>:
> On Tue, May 05, 2009 at 08:36:19PM +0200, Stefan Lippers-Hollmann wrote:
>> Hi
>>
>> On Dienstag, 5. Mai 2009, gregkh@suse.de wrote:
>> [...]
>> > From 00a62ce91e554198ef28234c91c36f850f5a3bc9 Mon Sep 17 00:00:00 2001
>> > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> > Date: Thu, 30 Apr 2009 15:08:51 -0700
>> > Subject: mm: fix Committed_AS underflow on large NR_CPUS environment
>> >
>> > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> >
>> > commit 00a62ce91e554198ef28234c91c36f850f5a3bc9 upstream.
>> >
>> > The Committed_AS field can underflow in certain situations:
>> >
>> > >         # while true; do cat /proc/meminfo  | grep _AS; sleep 1; done | uniq -c
>> > >               1 Committed_AS: 18446744073709323392 kB
>> > >              11 Committed_AS: 18446744073709455488 kB
>> > >               6 Committed_AS:    35136 kB
>> > >               5 Committed_AS: 18446744073709454400 kB
>> > >               7 Committed_AS:    35904 kB
>> > >               3 Committed_AS: 18446744073709453248 kB
>> > >               2 Committed_AS:    34752 kB
>> > >               9 Committed_AS: 18446744073709453248 kB
>> > >               8 Committed_AS:    34752 kB
>> > >               3 Committed_AS: 18446744073709320960 kB
>> > >               7 Committed_AS: 18446744073709454080 kB
>> > >               3 Committed_AS: 18446744073709320960 kB
>> > >               5 Committed_AS: 18446744073709454080 kB
>> > >               6 Committed_AS: 18446744073709320960 kB
>> >
>> > Because NR_CPUS can be greater than 1000 and meminfo_proc_show() does
>> > not check for underflow.
>> >
>> > But NR_CPUS proportional isn't good calculation.  In general,
>> > possibility of lock contention is proportional to the number of online
>> > cpus, not theorical maximum cpus (NR_CPUS).
>> >
>> > The current kernel has generic percpu-counter stuff.  using it is right
>> > way.  it makes code simplify and percpu_counter_read_positive() don't
>> > make underflow issue.
>>
>> This patch reproducably panics on all systems I could test so far on
>> 2.6.29.2 + the current stable queue:
>> - Acer Aspire One, Intel Atom N270, Intel 945GC chipset (i386)
>> - AMD64 3200+, nVidia nforce3 chipset (amd64)
>> - AMD64 X2 4200+, nVidia nforce4 chipset (amd64)
>>
>> Kernel panic (sorry, this is from a bad webcam and only the last part of
>> the messages scrolling by - I can try to get a serial console tomorrow),
>> taken from an AMD64 3200+, nVidia nforce3 chipset (amd64).
>> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/panic.gif [198 KB]
>>
>> Reverting just this patch fixes the problem for me.
>>
>> Kernel configurations:
>> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/config-2.6.29-2.slh.5.3-sidux-686   [96 KB]
>> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/config-2.6.29-2.slh.5.6-sidux-amd64 [91 KB]
>
> Yes, I just confirmed this on my machines as well, so I'm going to drop
> it from the stable queue.
>
> If anyone thinks it is really necessary for the 2.6.29-stable tree,
> please resubmit it after fixing it and testing that it works :)
>
> thanks,

Could you please post oops log?
current mmotm (include this patch) works fine on my x86_64 box. Then,
I have no hint now ;-)

Re: patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree

[Greg KH]

On Wed, May 06, 2009 at 07:26:51AM +0900, KOSAKI Motohiro wrote:
> 2009/5/6 Greg KH <gregkh@suse.de>:
> > On Tue, May 05, 2009 at 08:36:19PM +0200, Stefan Lippers-Hollmann wrote:
> >> Hi
> >>
> >> On Dienstag, 5. Mai 2009, gregkh@suse.de wrote:
> >> [...]
> >> > From 00a62ce91e554198ef28234c91c36f850f5a3bc9 Mon Sep 17 00:00:00 2001
> >> > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> >> > Date: Thu, 30 Apr 2009 15:08:51 -0700
> >> > Subject: mm: fix Committed_AS underflow on large NR_CPUS environment
> >> >
> >> > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> >> >
> >> > commit 00a62ce91e554198ef28234c91c36f850f5a3bc9 upstream.
> >> >
> >> > The Committed_AS field can underflow in certain situations:
> >> >
> >> > >         # while true; do cat /proc/meminfo  | grep _AS; sleep 1; done | uniq -c
> >> > >               1 Committed_AS: 18446744073709323392 kB
> >> > >              11 Committed_AS: 18446744073709455488 kB
> >> > >               6 Committed_AS:    35136 kB
> >> > >               5 Committed_AS: 18446744073709454400 kB
> >> > >               7 Committed_AS:    35904 kB
> >> > >               3 Committed_AS: 18446744073709453248 kB
> >> > >               2 Committed_AS:    34752 kB
> >> > >               9 Committed_AS: 18446744073709453248 kB
> >> > >               8 Committed_AS:    34752 kB
> >> > >               3 Committed_AS: 18446744073709320960 kB
> >> > >               7 Committed_AS: 18446744073709454080 kB
> >> > >               3 Committed_AS: 18446744073709320960 kB
> >> > >               5 Committed_AS: 18446744073709454080 kB
> >> > >               6 Committed_AS: 18446744073709320960 kB
> >> >
> >> > Because NR_CPUS can be greater than 1000 and meminfo_proc_show() does
> >> > not check for underflow.
> >> >
> >> > But NR_CPUS proportional isn't good calculation.  In general,
> >> > possibility of lock contention is proportional to the number of online
> >> > cpus, not theorical maximum cpus (NR_CPUS).
> >> >
> >> > The current kernel has generic percpu-counter stuff.  using it is right
> >> > way.  it makes code simplify and percpu_counter_read_positive() don't
> >> > make underflow issue.
> >>
> >> This patch reproducably panics on all systems I could test so far on
> >> 2.6.29.2 + the current stable queue:
> >> - Acer Aspire One, Intel Atom N270, Intel 945GC chipset (i386)
> >> - AMD64 3200+, nVidia nforce3 chipset (amd64)
> >> - AMD64 X2 4200+, nVidia nforce4 chipset (amd64)
> >>
> >> Kernel panic (sorry, this is from a bad webcam and only the last part of
> >> the messages scrolling by - I can try to get a serial console tomorrow),
> >> taken from an AMD64 3200+, nVidia nforce3 chipset (amd64).
> >> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/panic.gif [198 KB]
> >>
> >> Reverting just this patch fixes the problem for me.
> >>
> >> Kernel configurations:
> >> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/config-2.6.29-2.slh.5.3-sidux-686   [96 KB]
> >> http://sidux.com/slh/mm-fix-committed_as-underflow-on-large-nr_cpus-environment/config-2.6.29-2.slh.5.6-sidux-amd64 [91 KB]
> >
> > Yes, I just confirmed this on my machines as well, so I'm going to drop
> > it from the stable queue.
> >
> > If anyone thinks it is really necessary for the 2.6.29-stable tree,
> > please resubmit it after fixing it and testing that it works :)
> >
> > thanks,
> 
> Could you please post oops log?
> current mmotm (include this patch) works fine on my x86_64 box. Then,
> I have no hint now ;-)

Ok, I'll apply the patch and reboot and take a picture of it...

Re: patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree

[KOSAKI Motohiro]

>> Could you please post oops log?
>> current mmotm (include this patch) works fine on my x86_64 box. Then,
>> I have no hint now ;-)
>
> Ok, I'll apply the patch and reboot and take a picture of it...

umm.

Greg, your stable queue has following function?
2.6.29.2 + this patch don't make correct mmap_init() on my box.
(instead, changing unrelated function)

Please check.

--------------------------------------------------------------------------------------
/*
 * initialise the VMA slab
 */
void __init mmap_init(void)
{
        int ret;

        ret = percpu_counter_init(&vm_committed_as, 0);
        VM_BUG_ON(ret);
        vm_area_cachep = kmem_cache_create("vm_area_struct",
                        sizeof(struct vm_area_struct), 0,
                        SLAB_PANIC, NULL);
}
--------------------------------------------------------------------------------------

Re: patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree

[Greg KH]

[-- Attachment #1: Type: text/plain, Size: 261 bytes --]

On Wed, May 06, 2009 at 07:26:51AM +0900, KOSAKI Motohiro wrote:
> Could you please post oops log?
> current mmotm (include this patch) works fine on my x86_64 box. Then,
> I have no hint now ;-)

Attached is a picture of the oops.

Hope this helps,

greg k-h


[-- Attachment #2: mm-fix-oops.jpg --]
[-- Type: image/jpeg, Size: 163475 bytes --]

Re: patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree

[KOSAKI Motohiro]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

> On Wed, May 06, 2009 at 07:26:51AM +0900, KOSAKI Motohiro wrote:
>> Could you please post oops log?
>> current mmotm (include this patch) works fine on my x86_64 box. Then,
>> I have no hint now ;-)
>
> Attached is a picture of the oops.
>
> Hope this helps,

OK, the reason is 99% mis-applied patch. I've made rebased patch.

in my environment

2.6.29.2 + original patch:  panic
2.6.29.2 + rebased patch:  works well

Could you please try it?

[-- Attachment #2: committed_as-for-2.6.29.2.patch --]
[-- Type: application/octet-stream, Size: 7816 bytes --]

commit 12adffadf709dd675f736d7d848e24c3db03a1e4
Author: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Date:   Tue Apr 28 22:48:11 2009 +0200

    The Committed_AS field can underflow in certain situations:
    
    >         # while true; do cat /proc/meminfo  | grep _AS; sleep 1; done | uniq -c
    >               1 Committed_AS: 18446744073709323392 kB
    >              11 Committed_AS: 18446744073709455488 kB
    >               6 Committed_AS:    35136 kB
    >               5 Committed_AS: 18446744073709454400 kB
    >               7 Committed_AS:    35904 kB
    >               3 Committed_AS: 18446744073709453248 kB
    >               2 Committed_AS:    34752 kB
    >               9 Committed_AS: 18446744073709453248 kB
    >               8 Committed_AS:    34752 kB
    >               3 Committed_AS: 18446744073709320960 kB
    >               7 Committed_AS: 18446744073709454080 kB
    >               3 Committed_AS: 18446744073709320960 kB
    >               5 Committed_AS: 18446744073709454080 kB
    >               6 Committed_AS: 18446744073709320960 kB
    
    Because NR_CPUS can be greater than 1000 and meminfo_proc_show() does
    not check for underflow.
    
    But NR_CPUS proportional isn't good calculation.  In general,
    possibility of lock contention is proportional to the number of online
    cpus, not theorical maximum cpus (NR_CPUS).
    
    The current kernel has generic percpu-counter stuff.  using it is right
    way.  it makes code simplify and percpu_counter_read_positive() don't
    make underflow issue.
    
    Reported-by: Dave Hansen <dave@linux.vnet.ibm.com>
    Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Eric B Munson <ebmunson@us.ibm.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Christoph Lameter <cl@linux-foundation.org>
    Cc: <stable@kernel.org>		[All kernel versions]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

---
 fs/proc/meminfo.c    |    2 +-
 include/linux/mman.h |    9 +++------
 mm/mmap.c            |   12 ++++++------
 mm/nommu.c           |   13 +++++++------
 mm/swap.c            |   46 ----------------------------------------------
 5 files changed, 17 insertions(+), 65 deletions(-)

Index: b/fs/proc/meminfo.c
===================================================================
--- a/fs/proc/meminfo.c	2009-05-06 06:44:13.000000000 +0900
+++ b/fs/proc/meminfo.c	2009-05-06 07:33:05.000000000 +0900
@@ -35,7 +35,7 @@ static int meminfo_proc_show(struct seq_
 #define K(x) ((x) << (PAGE_SHIFT - 10))
 	si_meminfo(&i);
 	si_swapinfo(&i);
-	committed = atomic_long_read(&vm_committed_space);
+	committed = percpu_counter_read_positive(&vm_committed_as);
 	allowed = ((totalram_pages - hugetlb_total_pages())
 		* sysctl_overcommit_ratio / 100) + total_swap_pages;
 
Index: b/include/linux/mman.h
===================================================================
--- a/include/linux/mman.h	2009-05-06 06:45:18.000000000 +0900
+++ b/include/linux/mman.h	2009-05-06 07:33:05.000000000 +0900
@@ -12,21 +12,18 @@
 
 #ifdef __KERNEL__
 #include <linux/mm.h>
+#include <linux/percpu_counter.h>
 
 #include <asm/atomic.h>
 
 extern int sysctl_overcommit_memory;
 extern int sysctl_overcommit_ratio;
-extern atomic_long_t vm_committed_space;
+extern struct percpu_counter vm_committed_as;
 
-#ifdef CONFIG_SMP
-extern void vm_acct_memory(long pages);
-#else
 static inline void vm_acct_memory(long pages)
 {
-	atomic_long_add(pages, &vm_committed_space);
+	percpu_counter_add(&vm_committed_as, pages);
 }
-#endif
 
 static inline void vm_unacct_memory(long pages)
 {
Index: b/mm/mmap.c
===================================================================
--- a/mm/mmap.c	2009-05-06 06:47:34.000000000 +0900
+++ b/mm/mmap.c	2009-05-06 07:51:41.000000000 +0900
@@ -84,7 +84,7 @@ EXPORT_SYMBOL(vm_get_page_prot);
 int sysctl_overcommit_memory = OVERCOMMIT_GUESS;  /* heuristic overcommit */
 int sysctl_overcommit_ratio = 50;	/* default is 50% */
 int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT;
-atomic_long_t vm_committed_space = ATOMIC_LONG_INIT(0);
+struct percpu_counter vm_committed_as;
 
 /*
  * Check that a process has enough memory to allocate a new virtual
@@ -178,11 +178,7 @@ int __vm_enough_memory(struct mm_struct 
 	if (mm)
 		allowed -= mm->total_vm / 32;
 
-	/*
-	 * cast `allowed' as a signed long because vm_committed_space
-	 * sometimes has a negative value
-	 */
-	if (atomic_long_read(&vm_committed_space) < (long)allowed)
+	if (percpu_counter_read_positive(&vm_committed_as) < allowed)
 		return 0;
 error:
 	vm_unacct_memory(pages);
@@ -2477,6 +2473,10 @@ void mm_drop_all_locks(struct mm_struct 
  */
 void __init mmap_init(void)
 {
+	int ret;
+
+	ret = percpu_counter_init(&vm_committed_as, 0);
+	VM_BUG_ON(ret);
 	vm_area_cachep = kmem_cache_create("vm_area_struct",
 			sizeof(struct vm_area_struct), 0,
 			SLAB_PANIC, NULL);
Index: b/mm/nommu.c
===================================================================
--- a/mm/nommu.c	2009-05-06 06:35:33.000000000 +0900
+++ b/mm/nommu.c	2009-05-06 07:52:17.000000000 +0900
@@ -62,7 +62,7 @@ void *high_memory;
 struct page *mem_map;
 unsigned long max_mapnr;
 unsigned long num_physpages;
-atomic_long_t vm_committed_space = ATOMIC_LONG_INIT(0);
+struct percpu_counter vm_committed_as;
 int sysctl_overcommit_memory = OVERCOMMIT_GUESS; /* heuristic overcommit */
 int sysctl_overcommit_ratio = 50; /* default is 50% */
 int sysctl_max_map_count = DEFAULT_MAX_MAP_COUNT;
@@ -463,6 +463,10 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
  */
 void __init mmap_init(void)
 {
+	int ret;
+
+	ret = percpu_counter_init(&vm_committed_as, 0);
+	VM_BUG_ON(ret);
 	vm_region_jar = kmem_cache_create("vm_region_jar",
 					  sizeof(struct vm_region), 0,
 					  SLAB_PANIC, NULL);
@@ -1849,12 +1853,9 @@ int __vm_enough_memory(struct mm_struct 
 	if (mm)
 		allowed -= mm->total_vm / 32;
 
-	/*
-	 * cast `allowed' as a signed long because vm_committed_space
-	 * sometimes has a negative value
-	 */
-	if (atomic_long_read(&vm_committed_space) < (long)allowed)
+	if (percpu_counter_read_positive(&vm_committed_as) < allowed)
 		return 0;
+
 error:
 	vm_unacct_memory(pages);
 
Index: b/mm/swap.c
===================================================================
--- a/mm/swap.c	2009-05-06 06:35:34.000000000 +0900
+++ b/mm/swap.c	2009-05-06 07:33:05.000000000 +0900
@@ -514,49 +514,6 @@ unsigned pagevec_lookup_tag(struct pagev
 
 EXPORT_SYMBOL(pagevec_lookup_tag);
 
-#ifdef CONFIG_SMP
-/*
- * We tolerate a little inaccuracy to avoid ping-ponging the counter between
- * CPUs
- */
-#define ACCT_THRESHOLD	max(16, NR_CPUS * 2)
-
-static DEFINE_PER_CPU(long, committed_space);
-
-void vm_acct_memory(long pages)
-{
-	long *local;
-
-	preempt_disable();
-	local = &__get_cpu_var(committed_space);
-	*local += pages;
-	if (*local > ACCT_THRESHOLD || *local < -ACCT_THRESHOLD) {
-		atomic_long_add(*local, &vm_committed_space);
-		*local = 0;
-	}
-	preempt_enable();
-}
-
-#ifdef CONFIG_HOTPLUG_CPU
-
-/* Drop the CPU's cached committed space back into the central pool. */
-static int cpu_swap_callback(struct notifier_block *nfb,
-			     unsigned long action,
-			     void *hcpu)
-{
-	long *committed;
-
-	committed = &per_cpu(committed_space, (long)hcpu);
-	if (action == CPU_DEAD || action == CPU_DEAD_FROZEN) {
-		atomic_long_add(*committed, &vm_committed_space);
-		*committed = 0;
-		drain_cpu_pagevecs((long)hcpu);
-	}
-	return NOTIFY_OK;
-}
-#endif /* CONFIG_HOTPLUG_CPU */
-#endif /* CONFIG_SMP */
-
 /*
  * Perform any setup for the swap system
  */
@@ -577,7 +534,4 @@ void __init swap_setup(void)
 	 * Right now other parts of the system means that we
 	 * _really_ don't want to cluster much more
 	 */
-#ifdef CONFIG_HOTPLUG_CPU
-	hotcpu_notifier(cpu_swap_callback, 0);
-#endif
 }

Re: patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree

[Greg KH]

On Wed, May 06, 2009 at 08:12:21AM +0900, KOSAKI Motohiro wrote:
> > On Wed, May 06, 2009 at 07:26:51AM +0900, KOSAKI Motohiro wrote:
> >> Could you please post oops log?
> >> current mmotm (include this patch) works fine on my x86_64 box. Then,
> >> I have no hint now ;-)
> >
> > Attached is a picture of the oops.
> >
> > Hope this helps,
> 
> OK, the reason is 99% mis-applied patch. I've made rebased patch.
> 
> in my environment
> 
> 2.6.29.2 + original patch:  panic
> 2.6.29.2 + rebased patch:  works well
> 
> Could you please try it?

thank you for looking into this, I'll try it out tomorrow morning and
let you know how it goes.

greg k-h

Re: [stable] patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree

[Greg KH]

On Tue, May 05, 2009 at 11:20:58PM -0700, Greg KH wrote:
> On Wed, May 06, 2009 at 08:12:21AM +0900, KOSAKI Motohiro wrote:
> > > On Wed, May 06, 2009 at 07:26:51AM +0900, KOSAKI Motohiro wrote:
> > >> Could you please post oops log?
> > >> current mmotm (include this patch) works fine on my x86_64 box. Then,
> > >> I have no hint now ;-)
> > >
> > > Attached is a picture of the oops.
> > >
> > > Hope this helps,
> > 
> > OK, the reason is 99% mis-applied patch. I've made rebased patch.
> > 
> > in my environment
> > 
> > 2.6.29.2 + original patch:  panic
> > 2.6.29.2 + rebased patch:  works well
> > 
> > Could you please try it?
> 
> thank you for looking into this, I'll try it out tomorrow morning and
> let you know how it goes.

Yes, this works!

Thanks so much for working so quickly to resolve this.  I've added the
updated patch to the .29-stable queue.

greg k-h

Re: patch mm-fix-committed_as-underflow-on-large-nr_cpus-environment.patch added to 2.6.29-stable tree

[Stefan Lippers-Hollmann]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

Hi

On Mittwoch, 6. Mai 2009, KOSAKI Motohiro wrote:
> > On Wed, May 06, 2009 at 07:26:51AM +0900, KOSAKI Motohiro wrote:
> >> Could you please post oops log?
> >> current mmotm (include this patch) works fine on my x86_64 box. Then,
> >> I have no hint now ;-)
> >
> > Attached is a picture of the oops.
> >
> > Hope this helps,
> 
> OK, the reason is 99% mis-applied patch. I've made rebased patch.
> 
> in my environment
> 
> 2.6.29.2 + original patch:  panic
> 2.6.29.2 + rebased patch:  works well
> 
> Could you please try it?

This patch seems to fix the problems, it's working without any issues on 
all systems I could test so far.

Thank you
	Stefan Lippers-Hollmann

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]