Files
kernel_arpi/include/linux
KOSAKI Motohiro 00a62ce91e mm: fix Committed_AS underflow on large NR_CPUS environment
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>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-02 15:36:10 -07:00
..
2009-04-07 10:23:34 +01:00
2009-03-18 19:45:11 -07:00
2009-03-31 09:56:26 +01:00
2009-03-05 14:39:32 -05:00
2009-04-06 20:00:51 -04:00
2009-04-01 08:59:23 -07:00
2009-04-01 08:59:23 -07:00
2009-05-02 15:36:10 -07:00
2009-04-22 08:35:10 +02:00
2009-04-23 10:06:35 +01:00
2009-04-24 08:54:21 +02:00
2009-04-03 14:53:32 -07:00
2009-03-27 14:43:59 -04:00
2009-03-01 00:19:35 -08:00
2009-04-03 14:53:32 -07:00
2009-03-16 08:32:27 -06:00
2009-02-18 15:37:56 -08:00
2009-03-30 15:14:53 +02:00
2009-04-03 09:48:29 -07:00
2009-04-08 14:13:03 +02:00
2009-04-02 19:04:53 -07:00
2009-04-13 15:04:29 -07:00
2009-04-21 13:41:48 -07:00
2009-04-21 13:41:48 -07:00
2009-04-02 19:04:49 -07:00
2009-04-06 16:06:26 +01:00
2009-04-01 08:59:17 -07:00
2009-04-07 08:12:38 +02:00
2009-04-02 19:04:48 -07:00
2009-03-26 10:56:35 -07:00
2009-03-20 10:48:14 -07:00
2009-03-15 19:59:13 -07:00
2009-04-03 17:41:23 -07:00
2009-04-01 13:28:15 -04:00
2009-04-03 17:41:12 -07:00
2009-03-10 20:33:18 -04:00
2009-04-01 08:59:13 -07:00
2009-04-01 08:59:13 -07:00
2009-04-13 15:04:32 -07:00
2009-04-13 14:51:23 -07:00
2009-04-24 08:54:21 +02:00
2009-04-01 08:59:13 -07:00
2009-03-13 16:09:12 -07:00
2009-03-30 15:22:01 +02:00
2009-03-26 02:18:35 +01:00
2009-02-26 23:42:11 -08:00
2009-03-30 14:28:58 -07:00
2009-04-01 08:59:24 -07:00
2009-04-08 14:33:38 -07:00
2009-02-27 16:53:50 +09:00
2009-04-13 15:04:29 -07:00
2009-04-03 12:23:06 +02:00
2009-02-20 17:57:48 -08:00
2009-04-21 19:40:00 -07:00
2009-04-03 12:23:06 +02:00
2009-03-27 12:18:56 -04:00
2009-04-01 08:59:15 -07:00
2009-04-02 19:05:01 -07:00
2009-02-18 15:37:53 -08:00
2009-03-26 18:14:21 +01:00
2009-04-17 10:50:27 -07:00