Skip to contentSkip to conversation

New: kernel leaks a lot of memory

Bug 12832 Andrew Morton 5 participants 53 messages Mar 7, 2009 – Mar 12, 2009 3 messages not in the archive

Subsystems (3)
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author maintainer
#1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 27 lines · On Sat, 7 Mar 2009 11:27:12 -0800 (PST) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=12832

Summary: kernel leaks a lot of memory
Product: Memory Management
Version: 2.5
KernelVersion: 2.6.27
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]

Latest working kernel version: 2.6.26
Earliest failing kernel version: 2.6.27
Distribution: Fedora
Hardware Environment: x86_64
Software Environment: Fedora 9 & 10
Problem Description:

Starting from 2.6.27, the kernel eats up a whole lot more of memory (hundreds of MB) at no gain.

Quoted 7 lines

I've compared what I can from 2.6.26 and so far haven't found where this missing memory has disappeared.

Original bug in RH's bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=481448

hm, not a lot to go on there.

We have quite a lot of instrumentation for memory consumption - were you able to work out where it went by comparing /proc/meminfo, /proc/slabinfo, `echo m > /proc/sysrq-trigger', etc?

Is the memory missing on initial boot up, or does it take some time for the problem to become evident?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#2 lore raw
Quoted 7 lines · On Sat, 7 Mar 2009 12:24:52 -0800 Andrew Morton <[email protected]>…

hm, not a lot to go on there.

We have quite a lot of instrumentation for memory consumption - were you able to work out where it went by comparing /proc/meminfo, /proc/slabinfo, `echo m > /proc/sysrq-trigger', etc?

The redhat entry contains all the info, and I've compared meminfo and slabinfo without finding anything even close to the chunks of lost memory.

I've attached the sysrq memory stats from 2.6.26 and 2.6.27. The only difference though is in the reported free pages

I'm not very familiar with all the instrumentation, so pointers are very welcome.

Quoted 3 lines

Is the memory missing on initial boot up, or does it take some time for the problem to become evident?

Initial boot as far as I can tell.

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

Linux builder.drzeus.cx 2.6.26.6-79.fc9.x86_64 #1 SMP Fri Oct 17 14:20:33 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
SysRq : Show Memory
Mem-info:
Node 0 DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Node 0 DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 115
Active:8937 inactive:6285 dirty:48 writeback:0 unstable:0
free:103730 slab:5612 mapped:2148 pagetables:817 bounce:0
Node 0 DMA free:10292kB min:48kB low:60kB high:72kB active:0kB inactive:0kB present:8908kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 489 489 489
Node 0 DMA32 free:404628kB min:2804kB low:3504kB high:4204kB active:35748kB inactive:25140kB present:500896kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 3*4kB 5*8kB 4*16kB 4*32kB 3*64kB 3*128kB 3*256kB 3*512kB 3*1024kB 2*2048kB 0*4096kB = 10292kB
Node 0 DMA32: 3*4kB 5*8kB 2*16kB 2*32kB 2*64kB 1*128kB 3*256kB 2*512kB 3*1024kB 3*2048kB 96*4096kB = 404628kB
9730 total pagecache pages
Swap cache: add 0, delete 0, find 0/0
Free swap = 524280kB
Total swap = 524280kB
131056 pages of RAM
3772 reserved pages
7750 pages shared
0 pages swap cached

Linux builder.drzeus.cx 2.6.27.4-19.fc9.x86_64 #1 SMP Thu Oct 30 19:30:01 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
SysRq : Show Memory
Mem-Info:
Node 0 DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Node 0 DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 86
Active:8879 inactive:6265 dirty:8 writeback:0 unstable:0
free:62265 slab:5543 mapped:2154 pagetables:821 bounce:0
Node 0 DMA free:9448kB min:40kB low:48kB high:60kB active:0kB inactive:0kB present:7804kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 489 489 489
Node 0 DMA32 free:239612kB min:2808kB low:3508kB high:4212kB active:35516kB inactive:25060kB present:500896kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 2*16kB 5*32kB 4*64kB 2*128kB 2*256kB 2*512kB 3*1024kB 2*2048kB 0*4096kB = 9448kB
Node 0 DMA32: 1*4kB 7*8kB 6*16kB 1*32kB 1*64kB 4*128kB 3*256kB 3*512kB 1*1024kB 3*2048kB 56*4096kB = 239612kB
9692 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 524280kB
Total swap = 524280kB
131056 pages RAM
4046 pages reserved
7770 pages shared
61196 pages non-shared

author maintainer
#3 lore raw
Quoted 6 lines · On Sat, 7 Mar 2009 22:00:55 +0100 Pierre Ossman <[email protected]> wrote:
Quoted 3 lines · On Sat, 7 Mar 2009 12:24:52 -0800 Andrew Morton <[email protected]>…

hm, not a lot to go on there.

Quoted 8 lines
Quoted 4 lines

We have quite a lot of instrumentation for memory consumption - were you able to work out where it went by comparing /proc/meminfo, /proc/slabinfo, `echo m > /proc/sysrq-trigger', etc?

The redhat entry contains all the info, and I've compared meminfo and slabinfo without finding anything even close to the chunks of lost memory.

Ok.

Quoted 2 lines

I've attached the sysrq memory stats from 2.6.26 and 2.6.27. The only difference though is in the reported free pages

Drat.

Quoted 8 lines

I'm not very familiar with all the instrumentation, so pointers are very welcome.

Quoted 3 lines

Is the memory missing on initial boot up, or does it take some time for the problem to become evident?

Initial boot as far as I can tell.

OK. In that case it might be that someone gobbled a lot of bootmem.

Unfortunately we only added the bootmem_debug boot option in 2.6.27.

Below is a super-quick hackport of that patch into 2.6.26. That will allow us (ie: you ;)) to compare bootmem allocations between the two kernels.

Unfortunately bootmem-debugging doesn't tell us _who_ allocated the memory, so I stuck a dump_stack() in there too.

mm/bootmem.c renamed from mm/bootmem.c~bdebug +31 -4
diff -puN mm/bootmem.c~bdebug mm/bootmem.c
@@ -48,6 +48,22 @@ unsigned long __init bootmem_bootmap_pag
 	return mapsize;
 }
 
+static int bootmem_debug;
+
+static int __init bootmem_debug_setup(char *buf)
+{
+	bootmem_debug = 1;
+	return 0;
+}
+early_param("bootmem_debug", bootmem_debug_setup);
+
+#define bdebug(fmt, args...) ({				\
+	if (unlikely(bootmem_debug))			\
+		printk(KERN_INFO			\
+			"bootmem::%s " fmt,		\
+			__FUNCTION__, ## args);		\
+})
+
 /*
  * link bdata in order
  */
@@ -213,10 +229,10 @@ static void __init free_bootmem_core(boo
 	if (eidx > bdata->node_low_pfn - PFN_DOWN(bdata->node_boot_start))
 		eidx = bdata->node_low_pfn - PFN_DOWN(bdata->node_boot_start);
 
-	for (i = sidx; i < eidx; i++) {
-		if (unlikely(!test_and_clear_bit(i, bdata->node_bootmem_map)))
-			BUG();
-	}
+	for (i = sidx; i < eidx; i++)
+		if (test_and_set_bit(i, bdata->node_bootmem_map))
+			bdebug("hm, page %lx reserved twice.\n",
+				PFN_DOWN(bdata->node_boot_start) + i);
 }
 
 /*
@@ -252,6 +268,12 @@ __alloc_bootmem_core(struct bootmem_data
 	if (!bdata->node_bootmem_map)
 		return NULL;
 
+	bdebug("size=%lx [%lu pages] align=%lx goal=%lx limit=%lx\n",
+		size, PAGE_ALIGN(size) >> PAGE_SHIFT,
+		align, goal, limit);
+	if (bootmem_debug)
+		dump_stack();
+
 	/* bdata->node_boot_start is supposed to be (12+6)bits alignment on x86_64 ? */
 	node_boot_start = bdata->node_boot_start;
 	node_bootmem_map = bdata->node_bootmem_map;
@@ -359,6 +381,10 @@ found:
 		ret = phys_to_virt(start * PAGE_SIZE + node_boot_start);
 	}
 
+	bdebug("start=%lx end=%lx\n",
+		start + PFN_DOWN(bdata->node_boot_start),
+		start + areasize + PFN_DOWN(bdata->node_boot_start));
+
 	/*
 	 * Reserve the area now:
 	 */
@@ -432,6 +458,7 @@ static unsigned long __init free_all_boo
 	}
 	total += count;
 	bdata->node_bootmem_map = NULL;
+	bdebug("released=%lx\n", count);
 
 	return total;
 }

_

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#4 lore raw
Quoted 5 lines · On Sat, 7 Mar 2009 14:13:16 -0800 Andrew Morton <[email protected]>…

Below is a super-quick hackport of that patch into 2.6.26. That will allow us (ie: you ;)) to compare bootmem allocations between the two kernels.

Compiling...

I take it you couldn't see anything like this in your end?

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#5 lore raw
In reply to Andrew Morton
Quoted 8 lines · On Sat, 7 Mar 2009 14:13:16 -0800 Andrew Morton <[email protected]>…

Below is a super-quick hackport of that patch into 2.6.26. That will allow us (ie: you ;)) to compare bootmem allocations between the two kernels.

Unfortunately bootmem-debugging doesn't tell us _who_ allocated the memory, so I stuck a dump_stack() in there too.

I'm having problems booting this machine on a vanilla 2.26.6. Fedora's kernel works nice though, so I guess they have a bug fix for this. I've attached a screenshot in case it rings any bells.

I'm working on getting the data from the 2.6.27 kernel, but right now it doesn't seem like we're getting any numbers for comparison. :/

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#6 lore raw
Quoted 5 lines · On Sun, 8 Mar 2009 11:00:06 +0100 Pierre Ossman <[email protected]> wrote:

I'm having problems booting this machine on a vanilla 2.26.6. Fedora's kernel works nice though, so I guess they have a bug fix for this. I've attached a screenshot in case it rings any bells.

It turns out it's your backported patch that's the problem. I'll see if I can get it working. :)

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#7 lore raw
Quoted 11 lines · Pierre Ossman
Quoted 5 lines · On Sun, 8 Mar 2009 11:00:06 +0100 Pierre Ossman <[email protected]> wrote:

I'm having problems booting this machine on a vanilla 2.26.6. Fedora's kernel works nice though, so I guess they have a bug fix for this. I've attached a screenshot in case it rings any bells.

It turns out it's your backported patch that's the problem. I'll see if I can get it working. :)

Pierre, you can try the following fixed and combined patch and boot kernel with "initcall_debug bootmem_debug".

The boot hung was due to this chunk floated from reserve_bootmem_core() into free_bootmem_core()...

@@ -213,10 +229,10 @@ static void __init free_bootmem_core(boo
if (eidx > bdata->node_low_pfn - PFN_DOWN(bdata->node_boot_start))
eidx = bdata->node_low_pfn - PFN_DOWN(bdata->node_boot_start);

- for (i = sidx; i < eidx; i++) {
- if (unlikely(!test_and_clear_bit(i, bdata->node_bootmem_map)))
- BUG();
- }
+ for (i = sidx; i < eidx; i++)
+ if (test_and_set_bit(i, bdata->node_bootmem_map))
+ bdebug("hm, page %lx reserved twice.\n",
+ PFN_DOWN(bdata->node_boot_start) + i);
}

/*

Thanks,
Fengguang
---
From: Andrew Morton <[email protected]>

---
 init/main.c  |    2 ++
 mm/bootmem.c |   35 +++++++++++++++++++++++++++++++++++
 2 files changed, 37 insertions(+)
mm/bootmem.c +35 -0
@@ -48,6 +48,22 @@ unsigned long __init bootmem_bootmap_pag
 	return mapsize;
 }
 
+static int bootmem_debug;
+
+static int __init bootmem_debug_setup(char *buf)
+{
+	bootmem_debug = 1;
+	return 0;
+}
+early_param("bootmem_debug", bootmem_debug_setup);
+
+#define bdebug(fmt, args...) ({				\
+	if (unlikely(bootmem_debug))			\
+		printk(KERN_INFO			\
+			"bootmem::%s " fmt,		\
+			__FUNCTION__, ## args);		\
+})
+
 /*
  * link bdata in order
  */
@@ -172,6 +188,14 @@ static void __init reserve_bootmem_core(
 	if (eidx > bdata->node_low_pfn - PFN_DOWN(bdata->node_boot_start))
 		eidx = bdata->node_low_pfn - PFN_DOWN(bdata->node_boot_start);
 
+	bdebug("size=%lx [%lu pages] start=%lx end=%lx flags=%x\n",
+		size, PAGE_ALIGN(size) >> PAGE_SHIFT,
+		sidx + PFN_DOWN(bdata->node_boot_start),
+		eidx + PFN_DOWN(bdata->node_boot_start),
+		flags);
+	if (bootmem_debug)
+		dump_stack();
+
 	for (i = sidx; i < eidx; i++) {
 		if (test_and_set_bit(i, bdata->node_bootmem_map)) {
 #ifdef CONFIG_DEBUG_BOOTMEM
@@ -252,6 +276,12 @@ __alloc_bootmem_core(struct bootmem_data
 	if (!bdata->node_bootmem_map)
 		return NULL;
 
+	bdebug("size=%lx [%lu pages] align=%lx goal=%lx limit=%lx\n",
+		size, PAGE_ALIGN(size) >> PAGE_SHIFT,
+		align, goal, limit);
+	if (bootmem_debug)
+		dump_stack();
+
 	/* bdata->node_boot_start is supposed to be (12+6)bits alignment on x86_64 ? */
 	node_boot_start = bdata->node_boot_start;
 	node_bootmem_map = bdata->node_bootmem_map;
@@ -359,6 +389,10 @@ found:
 		ret = phys_to_virt(start * PAGE_SIZE + node_boot_start);
 	}
 
+	bdebug("start=%lx end=%lx\n",
+		start + PFN_DOWN(bdata->node_boot_start),
+		start + areasize + PFN_DOWN(bdata->node_boot_start));
+
 	/*
 	 * Reserve the area now:
 	 */
@@ -432,6 +466,7 @@ static unsigned long __init free_all_boo
 	}
 	total += count;
 	bdata->node_bootmem_map = NULL;
+	bdebug("released=%lx\n", count);
 
 	return total;
 }
init/main.c +2 -0
@@ -60,6 +60,7 @@
 #include <linux/sched.h>
 #include <linux/signal.h>
 #include <linux/idr.h>
+#include <linux/swap.h>
 
 #include <asm/io.h>
 #include <asm/bugs.h>
@@ -714,6 +715,7 @@ static void __init do_one_initcall(initc
 		print_fn_descriptor_symbol("initcall %s", fn);
 		printk(" returned %d after %Ld msecs\n", result,
 			(unsigned long long) delta.tv64 >> 20);
+		printk("remaining memory: %d\n", nr_free_buffer_pages());
 	}
 
 	msgbuf[0] = 0;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#8 lore raw
Quoted 7 lines · On Sun, 8 Mar 2009 20:38:25 +0800 Wu Fengguang <[email protected]> wrote:

Pierre, you can try the following fixed and combined patch and boot kernel with "initcall_debug bootmem_debug".

The boot hung was due to this chunk floated from reserve_bootmem_core() into free_bootmem_core()...

Yeah, I found that as well. I'm getting a decent output now.

Included are the dmesg dumps of bootmem_debug. I'll get the initcall stuff in a bit.

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#9 lore raw
In reply to Wu Fengguang

I've gone through the dumps now, and still no meaningful difference. All the big bootmem allocations are present in both kernels, and the remaining memory in initcall is also the same for both (and doesn't really decrease by any meaningful amount).

I also tried booting with init=/bin/sh, and the lost memory is present even at that point.

More ideas?

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
author maintainer
#10 lore raw
Quoted 8 lines · On Sun, 8 Mar 2009 16:54:03 +0100 Pierre Ossman <[email protected]> wrote:

I've gone through the dumps now, and still no meaningful difference. All the big bootmem allocations are present in both kernels, and the remaining memory in initcall is also the same for both (and doesn't really decrease by any meaningful amount).

I also tried booting with init=/bin/sh, and the lost memory is present even at that point.

So we know that the memory gets consumed after end-of-initcalls and before exec-of-init?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#11 lore raw
Quoted 7 lines · On Sun, 8 Mar 2009 12:11:43 -0700 Andrew Morton <[email protected]>…
Quoted 5 lines · On Sun, 8 Mar 2009 16:54:03 +0100 Pierre Ossman <[email protected]> wrote:

I've gone through the dumps now, and still no meaningful difference. All the big bootmem allocations are present in both kernels, and the remaining memory in initcall is also the same for both (and doesn't really decrease by any meaningful amount).

Quoted 6 lines
Quoted 3 lines

I also tried booting with init=/bin/sh, and the lost memory is present even at that point.

So we know that the memory gets consumed after end-of-initcalls and before exec-of-init?

This is a fedora machine, so initrd might be the provoking party here. I haven't yet tried the adventure of booting without initrd. It's after initcalls at least.

Right now I'm compiling 2.6.27-rc1 in an effort to bisect this, but if you have something more worthwhile then shoot. :)

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
author maintainer
#12 lore raw
In reply to Pierre Ossman

Now another possibility is that someone is gobbling lots of memory during initcalls.

So here's an untested addition to the `initcall_debug' boot option which should permit us to work out how much memory each initcall consumed:

init/main.c renamed from init/main.c~a +1 -0
@@ -714,6 +714,7 @@ static void __init do_one_initcall(initc
 		print_fn_descriptor_symbol("initcall %s", fn);
 		printk(" returned %d after %Ld msecs\n", result,
 			(unsigned long long) delta.tv64 >> 20);
+		printk("remaining memory: %d\n", nr_free_buffer_pages());
 	}
 
 	msgbuf[0] = 0;

_

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#13 lore raw
In reply to Pierre Ossman

Hi Pierre,

Quoted 6 lines · Pierre Ossman
Quoted 3 lines · On Sat, 7 Mar 2009 12:24:52 -0800 Andrew Morton <[email protected]>…

hm, not a lot to go on there.

Quoted 8 lines
Quoted 4 lines

We have quite a lot of instrumentation for memory consumption - were you able to work out where it went by comparing /proc/meminfo, /proc/slabinfo, `echo m > /proc/sysrq-trigger', etc?

The redhat entry contains all the info, and I've compared meminfo and slabinfo without finding anything even close to the chunks of lost memory.

The "free" pages in sysrq mem-info report should be equal to "MemFree" in /proc/meminfo. So I'd expect meminfo numbers to be different in .26/.27 as well.

Maybe the memory is taken by some user space program, so it would be helpful to know the numbers in /proc/meminfo, /proc/vmstat and /proc/zoneinfo.

Quoted 2 lines

I've attached the sysrq memory stats from 2.6.26 and 2.6.27. The only difference though is in the reported free pages

The "free" entries in mem-info:

                     2.6.26     2.6.27

--------------------------------------
free: 103730 62265 (pages)
Node 0 DMA free: 10292kB 9448kB
Node 0 DMA32 free:404628kB 239612kB

So there are 160MB less free pages in .27. Are you sure that initrd is freed after booting?

Thanks,
Fengguang

Quoted 69 lines

I'm not very familiar with all the instrumentation, so pointers are very welcome.

Quoted 3 lines

Is the memory missing on initial boot up, or does it take some time for the problem to become evident?

Initial boot as far as I can tell.

Rgds

Signature · 56 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

Linux builder.drzeus.cx 2.6.26.6-79.fc9.x86_64 #1 SMP Fri Oct 17 14:20:33 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
SysRq : Show Memory
Mem-info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd: 115
Active:8937 inactive:6285 dirty:48 writeback:0 unstable:0
 free:103730 slab:5612 mapped:2148 pagetables:817 bounce:0
Node 0 DMA free:10292kB min:48kB low:60kB high:72kB active:0kB inactive:0kB present:8908kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 489 489 489
Node 0 DMA32 free:404628kB min:2804kB low:3504kB high:4204kB active:35748kB inactive:25140kB present:500896kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 3*4kB 5*8kB 4*16kB 4*32kB 3*64kB 3*128kB 3*256kB 3*512kB 3*1024kB 2*2048kB 0*4096kB = 10292kB
Node 0 DMA32: 3*4kB 5*8kB 2*16kB 2*32kB 2*64kB 1*128kB 3*256kB 2*512kB 3*1024kB 3*2048kB 96*4096kB = 404628kB
9730 total pagecache pages
Swap cache: add 0, delete 0, find 0/0
Free swap  = 524280kB
Total swap = 524280kB
131056 pages of RAM
3772 reserved pages
7750 pages shared
0 pages swap cached


Linux builder.drzeus.cx 2.6.27.4-19.fc9.x86_64 #1 SMP Thu Oct 30 19:30:01 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
SysRq : Show Memory
Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:  86
Active:8879 inactive:6265 dirty:8 writeback:0 unstable:0
 free:62265 slab:5543 mapped:2154 pagetables:821 bounce:0
Node 0 DMA free:9448kB min:40kB low:48kB high:60kB active:0kB inactive:0kB present:7804kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 489 489 489
Node 0 DMA32 free:239612kB min:2808kB low:3508kB high:4212kB active:35516kB inactive:25060kB present:500896kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 2*16kB 5*32kB 4*64kB 2*128kB 2*256kB 2*512kB 3*1024kB 2*2048kB 0*4096kB = 9448kB
Node 0 DMA32: 1*4kB 7*8kB 6*16kB 1*32kB 1*64kB 4*128kB 3*256kB 3*512kB 1*1024kB 3*2048kB 56*4096kB = 239612kB
9692 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 524280kB
Total swap = 524280kB
131056 pages RAM
4046 pages reserved
7770 pages shared
61196 pages non-shared

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

A message that is not in the archive (sent off-list or not yet received): 20090309020701.GA381@localhost

#15 lore raw
Quoted 6 lines · On Mon, 9 Mar 2009 10:07:01 +0800 Wu Fengguang <[email protected]> wrote:
Quoted 5 lines · Wu Fengguang

The "free" pages in sysrq mem-info report should be equal to "MemFree" in /proc/meminfo. So I'd expect meminfo numbers to be different in .26/.27 as well.

Quoted 6 lines
Quoted 3 lines

Maybe the memory is taken by some user space program, so it would be helpful to know the numbers in /proc/meminfo, /proc/vmstat and /proc/zoneinfo.

And maybe piggyback /proc/slabinfo in case it is a kernel bug :-)

Big dump of relevant /proc files:

[root@builder ~]# free
total used free shared buffers cached

Mem:        509108     236988     272120          0        228      14760
-/+ buffers/cache:     222000     287108
Swap:       524280        228     524052

[root@builder ~]# cat /proc/meminfo

MemTotal:       509108 kB
MemFree:        272172 kB
Buffers:           240 kB
Cached:          14788 kB
SwapCached:         64 kB
Active:          32544 kB
Inactive:         5900 kB
SwapTotal:      524280 kB
SwapFree:       524052 kB
Dirty:            5980 kB
Writeback:           0 kB
AnonPages:       23404 kB
Mapped:           8648 kB
Slab:            23148 kB
SReclaimable:     5420 kB
SUnreclaim:      17728 kB
PageTables:       3324 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:    778832 kB
Committed_AS:    85196 kB
VmallocTotal: 34359738367 kB
VmallocUsed:      1740 kB
VmallocChunk: 34359736619 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     2048 kB
DirectMap4k:      2032
DirectMap2M:  18446744073709551613
DirectMap1G:         0

[root@builder ~]# cat /proc/vmstat
nr_free_pages 68035
nr_inactive 1479
nr_active 8137
nr_anon_pages 5851
nr_mapped 2162
nr_file_pages 3777
nr_dirty 132
nr_writeback 0
nr_slab_reclaimable 1354
nr_slab_unreclaimable 4440
nr_page_table_pages 831
nr_unstable 0
nr_bounce 0
nr_vmscan_write 324
nr_writeback_temp 0
numa_hit 18985527
numa_miss 0
numa_foreign 0
numa_interleave 44220
numa_local 18985527
numa_other 0
pgpgin 379025
pgpgout 820238
pswpin 16
pswpout 57
pgalloc_dma 295454
pgalloc_dma32 18721928
pgalloc_normal 0
pgalloc_movable 0
pgfree 19085491
pgactivate 60797
pgdeactivate 47199
pgfault 25624481
pgmajfault 2490
pgrefill_dma 8144
pgrefill_dma32 103508
pgrefill_normal 0
pgrefill_movable 0
pgsteal_dma 4503
pgsteal_dma32 179395
pgsteal_normal 0
pgsteal_movable 0
pgscan_kswapd_dma 4999
pgscan_kswapd_dma32 180546
pgscan_kswapd_normal 0
pgscan_kswapd_movable 0
pgscan_direct_dma 0
pgscan_direct_dma32 384
pgscan_direct_normal 0
pgscan_direct_movable 0
pginodesteal 0
slabs_scanned 153856
kswapd_steal 183628
kswapd_inodesteal 35303
pageoutrun 3794
allocstall 3
pgrotated 72
htlb_buddy_alloc_success 0
htlb_buddy_alloc_fail 0

[root@builder ~]# cat /proc/zoneinfo
Node 0, zone DMA

  pages free     2524
        min      12
        low      15
        high     18
        scanned  0 (a: 27 i: 24)
        spanned  4096
        present  2180
    nr_free_pages 2524
    nr_inactive  0
    nr_active    8
    nr_anon_pages 8
    nr_mapped    0
    nr_file_pages 0
    nr_dirty     0
    nr_writeback 0
    nr_slab_reclaimable 16
    nr_slab_unreclaimable 7
    nr_page_table_pages 15
    nr_unstable  0
    nr_bounce    0
    nr_vmscan_write 292
    nr_writeback_temp 0
    numa_hit     295370
    numa_miss    0
    numa_foreign 0
    numa_interleave 0
    numa_local   295370
    numa_other   0
        protection: (0, 489, 489, 489)
  pagesets
    cpu: 0
              count: 0
              high:  0
              batch: 1

vm stats threshold: 2
all_unreclaimable: 0
prev_priority: 12
start_pfn: 0
Node 0, zone DMA32

  pages free     65515
        min      700
        low      875
        high     1050
        scanned  0 (a: 0 i: 0)
        spanned  126960
        present  125224
    nr_free_pages 65515
    nr_inactive  1482
    nr_active    8137
    nr_anon_pages 5843
    nr_mapped    2162
    nr_file_pages 3789
    nr_dirty     128
    nr_writeback 0
    nr_slab_reclaimable 1331
    nr_slab_unreclaimable 4429
    nr_page_table_pages 816
    nr_unstable  0
    nr_bounce    0
    nr_vmscan_write 32
    nr_writeback_temp 0
    numa_hit     18690260
    numa_miss    0
    numa_foreign 0
    numa_interleave 44220
    numa_local   18690260
    numa_other   0
        protection: (0, 0, 0, 0)
  pagesets
    cpu: 0
              count: 69
              high:  186
              batch: 31

vm stats threshold: 6
all_unreclaimable: 0
prev_priority: 12
start_pfn: 4096

[root@builder ~]# cat /proc/slabinfo
slabinfo - version: 2.1

# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
rpc_inode_cache       39     39    832   39    8 : tunables    0    0    0 : slabdata      1      1      0
nf_conntrack_expect      0      0    240   34    2 : tunables    0    0    0 : slabdata      0      0      0
UDPv6                 34     34    960   34    8 : tunables    0    0    0 : slabdata      1      1      0
TCPv6                 18     18   1792   18    8 : tunables    0    0    0 : slabdata      1      1      0
kmalloc_dma-512       32     32    512   32    4 : tunables    0    0    0 : slabdata      1      1      0
dm_snap_pending_exception    144    144    112   36    1 : tunables    0    0    0 : slabdata      4      4      0
kcopyd_job             0      0    360   45    4 : tunables    0    0    0 : slabdata      0      0      0
dm_uevent              0      0   2608   12    8 : tunables    0    0    0 : slabdata      0      0      0
ext3_inode_cache     387   1554    768   42    8 : tunables    0    0    0 : slabdata     37     37      0
ext3_xattr            46     46     88   46    1 : tunables    0    0    0 : slabdata      1      1      0
journal_handle       170    170     24  170    1 : tunables    0    0    0 : slabdata      1      1      0
journal_head          42     42     96   42    1 : tunables    0    0    0 : slabdata      1      1      0
revoke_table         256    256     16  256    1 : tunables    0    0    0 : slabdata      1      1      0
revoke_record        128    128     32  128    1 : tunables    0    0    0 : slabdata      1      1      0
cfq_io_context        44     48    168   24    1 : tunables    0    0    0 : slabdata      2      2      0
mqueue_inode_cache     36     36    896   36    8 : tunables    0    0    0 : slabdata      1      1      0
isofs_inode_cache      0      0    616   26    4 : tunables    0    0    0 : slabdata      0      0      0
hugetlbfs_inode_cache     28     28    584   28    4 : tunables    0    0    0 : slabdata      1      1      0
dquot                  0      0    256   32    2 : tunables    0    0    0 : slabdata      0      0      0
inotify_event_cache    612    612     40  102    1 : tunables    0    0    0 : slabdata      6      6      0
fasync_cache      313798 313820     24  170    1 : tunables    0    0    0 : slabdata   1846   1846      0
shmem_inode_cache    735    738    792   41    8 : tunables    0    0    0 : slabdata     18     18      0
pid_namespace          0      0   2104   15    8 : tunables    0    0    0 : slabdata      0      0      0
nsproxy                0      0     56   73    1 : tunables    0    0    0 : slabdata      0      0      0
UNIX                  92     92    704   46    8 : tunables    0    0    0 : slabdata      2      2      0
xfrm_dst_cache         0      0    384   42    4 : tunables    0    0    0 : slabdata      0      0      0
ip_dst_cache          51     75    320   25    2 : tunables    0    0    0 : slabdata      3      3      0
TCP                   19     19   1664   19    8 : tunables    0    0    0 : slabdata      1      1      0
blkdev_integrity       0      0    120   34    1 : tunables    0    0    0 : slabdata      0      0      0
blkdev_queue          34     34   1824   17    8 : tunables    0    0    0 : slabdata      2      2      0
blkdev_requests       38     52    304   26    2 : tunables    0    0    0 : slabdata      2      2      0
sock_inode_cache     138    138    704   46    8 : tunables    0    0    0 : slabdata      3      3      0
file_lock_cache       42     42    192   42    2 : tunables    0    0    0 : slabdata      1      1      0
taskstats             26     26    312   26    2 : tunables    0    0    0 : slabdata      1      1      0
proc_inode_cache      90    162    600   27    4 : tunables    0    0    0 : slabdata      6      6      0
sigqueue              25     25    160   25    1 : tunables    0    0    0 : slabdata      1      1      0
radix_tree_node      623   2581    560   29    4 : tunables    0    0    0 : slabdata     89     89      0
bdev_cache            42     42    768   42    8 : tunables    0    0    0 : slabdata      1      1      0
sysfs_dir_cache     7084   7089     80   51    1 : tunables    0    0    0 : slabdata    139    139      0
inode_cache         1505   1708    568   28    4 : tunables    0    0    0 : slabdata     61     61      0
dentry              2555   4485    208   39    2 : tunables    0    0    0 : slabdata    115    115      0
avc_node            1735   2128     72   56    1 : tunables    0    0    0 : slabdata     38     38      0
buffer_head         1583   5472    112   36    1 : tunables    0    0    0 : slabdata    152    152      0
mm_struct             75     78    832   39    8 : tunables    0    0    0 : slabdata      2      2      0
vm_area_struct      2223   2438    176   46    2 : tunables    0    0    0 : slabdata     53     53      0
files_cache           78     84    768   42    8 : tunables    0    0    0 : slabdata      2      2      0
signal_cache         105    108    896   36    8 : tunables    0    0    0 : slabdata      3      3      0
sighand_cache         85     90   2112   15    8 : tunables    0    0    0 : slabdata      6      6      0
task_struct          141    145   5840    5    8 : tunables    0    0    0 : slabdata     29     29      0
anon_vma             741    768     32  128    1 : tunables    0    0    0 : slabdata      6      6      0
shared_policy_node     85     85     48   85    1 : tunables    0    0    0 : slabdata      1      1      0
numa_policy           56     60    136   30    1 : tunables    0    0    0 : slabdata      2      2      0
idr_layer_cache      269    270    536   30    4 : tunables    0    0    0 : slabdata      9      9      0
kmalloc-4096         247    248   4096    8    8 : tunables    0    0    0 : slabdata     31     31      0
kmalloc-2048         345    352   2048   16    8 : tunables    0    0    0 : slabdata     22     22      0
kmalloc-1024         396    416   1024   32    8 : tunables    0    0    0 : slabdata     13     13      0
kmalloc-512          297    320    512   32    4 : tunables    0    0    0 : slabdata     10     10      0
kmalloc-256          985    992    256   32    2 : tunables    0    0    0 : slabdata     31     31      0
kmalloc-128         1899   2016    128   32    1 : tunables    0    0    0 : slabdata     63     63      0
kmalloc-64          6795   9600     64   64    1 : tunables    0    0    0 : slabdata    150    150      0
kmalloc-32         20735  20736     32  128    1 : tunables    0    0    0 : slabdata    162    162      0
kmalloc-16        138778 139264     16  256    1 : tunables    0    0    0 : slabdata    544    544      0
kmalloc-8           8190   8192      8  512    1 : tunables    0    0    0 : slabdata     16     16      0
kmalloc-192          972   1050    192   42    2 : tunables    0    0    0 : slabdata     25     25      0
kmalloc-96          2815   2856     96   42    1 : tunables    0    0    0 : slabdata     68     68      0
kmem_cache_node        0      0     64   64    1 : tunables    0    0    0 : slabdata      0      0      0
Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#16 lore raw

Hi Pierre,

Quoted 9 lines · Pierre Ossman
Quoted 6 lines · On Mon, 9 Mar 2009 10:07:01 +0800 Wu Fengguang <[email protected]> wrote:
Quoted 5 lines · Wu Fengguang

The "free" pages in sysrq mem-info report should be equal to "MemFree" in /proc/meminfo. So I'd expect meminfo numbers to be different in .26/.27 as well.

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

Maybe the memory is taken by some user space program, so it would be helpful to know the numbers in /proc/meminfo, /proc/vmstat and /proc/zoneinfo.

And maybe piggyback /proc/slabinfo in case it is a kernel bug :-)

Big dump of relevant /proc files:

Thanks for the data! Now it seems that some pages are totally missing from bootmem or slabs or page cache or any application consumptions...

Will searching through /proc/kpageflags for reserved pages help identify the problem?

Oh kpageflags_read() does not include support for PG_reserved:

        #define KPF_LOCKED     0
        #define KPF_ERROR      1
        #define KPF_REFERENCED 2
        #define KPF_UPTODATE   3
        #define KPF_DIRTY      4
        #define KPF_LRU        5
        #define KPF_ACTIVE     6
        #define KPF_SLAB       7
        #define KPF_WRITEBACK  8
        #define KPF_RECLAIM    9
        #define KPF_BUDDY     10

Thanks,
Fengguang

Quoted 31 lines

[root@builder ~]# free
total used free shared buffers cached

Mem:        509108     236988     272120          0        228      14760
-/+ buffers/cache:     222000     287108
Swap:       524280        228     524052

[root@builder ~]# cat /proc/meminfo

MemTotal:       509108 kB
MemFree:        272172 kB
Buffers:           240 kB
Cached:          14788 kB
SwapCached:         64 kB
Active:          32544 kB
Inactive:         5900 kB
SwapTotal:      524280 kB
SwapFree:       524052 kB
Dirty:            5980 kB
Writeback:           0 kB
AnonPages:       23404 kB
Mapped:           8648 kB
Slab:            23148 kB
SReclaimable:     5420 kB
SUnreclaim:      17728 kB
PageTables:       3324 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:    778832 kB
Committed_AS:    85196 kB
VmallocTotal: 34359738367 kB
VmallocUsed:      1740 kB
Quoted 8 lines
VmallocChunk: 34359736619 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     2048 kB
DirectMap4k:      2032
DirectMap2M:  18446744073709551613

This field looks weird.

Quoted 204 lines

DirectMap1G: 0

[root@builder ~]# cat /proc/vmstat
nr_free_pages 68035
nr_inactive 1479
nr_active 8137
nr_anon_pages 5851
nr_mapped 2162
nr_file_pages 3777
nr_dirty 132
nr_writeback 0
nr_slab_reclaimable 1354
nr_slab_unreclaimable 4440
nr_page_table_pages 831
nr_unstable 0
nr_bounce 0
nr_vmscan_write 324
nr_writeback_temp 0
numa_hit 18985527
numa_miss 0
numa_foreign 0
numa_interleave 44220
numa_local 18985527
numa_other 0
pgpgin 379025
pgpgout 820238
pswpin 16
pswpout 57
pgalloc_dma 295454
pgalloc_dma32 18721928
pgalloc_normal 0
pgalloc_movable 0
pgfree 19085491
pgactivate 60797
pgdeactivate 47199
pgfault 25624481
pgmajfault 2490
pgrefill_dma 8144
pgrefill_dma32 103508
pgrefill_normal 0
pgrefill_movable 0
pgsteal_dma 4503
pgsteal_dma32 179395
pgsteal_normal 0
pgsteal_movable 0
pgscan_kswapd_dma 4999
pgscan_kswapd_dma32 180546
pgscan_kswapd_normal 0
pgscan_kswapd_movable 0
pgscan_direct_dma 0
pgscan_direct_dma32 384
pgscan_direct_normal 0
pgscan_direct_movable 0
pginodesteal 0
slabs_scanned 153856
kswapd_steal 183628
kswapd_inodesteal 35303
pageoutrun 3794
allocstall 3
pgrotated 72
htlb_buddy_alloc_success 0
htlb_buddy_alloc_fail 0

[root@builder ~]# cat /proc/zoneinfo
Node 0, zone DMA

  pages free     2524
        min      12
        low      15
        high     18
        scanned  0 (a: 27 i: 24)
        spanned  4096
        present  2180
    nr_free_pages 2524
    nr_inactive  0
    nr_active    8
    nr_anon_pages 8
    nr_mapped    0
    nr_file_pages 0
    nr_dirty     0
    nr_writeback 0
    nr_slab_reclaimable 16
    nr_slab_unreclaimable 7
    nr_page_table_pages 15
    nr_unstable  0
    nr_bounce    0
    nr_vmscan_write 292
    nr_writeback_temp 0
    numa_hit     295370
    numa_miss    0
    numa_foreign 0
    numa_interleave 0
    numa_local   295370
    numa_other   0
        protection: (0, 489, 489, 489)
  pagesets
    cpu: 0
              count: 0
              high:  0
              batch: 1

vm stats threshold: 2
all_unreclaimable: 0
prev_priority: 12
start_pfn: 0
Node 0, zone DMA32

  pages free     65515
        min      700
        low      875
        high     1050
        scanned  0 (a: 0 i: 0)
        spanned  126960
        present  125224
    nr_free_pages 65515
    nr_inactive  1482
    nr_active    8137
    nr_anon_pages 5843
    nr_mapped    2162
    nr_file_pages 3789
    nr_dirty     128
    nr_writeback 0
    nr_slab_reclaimable 1331
    nr_slab_unreclaimable 4429
    nr_page_table_pages 816
    nr_unstable  0
    nr_bounce    0
    nr_vmscan_write 32
    nr_writeback_temp 0
    numa_hit     18690260
    numa_miss    0
    numa_foreign 0
    numa_interleave 44220
    numa_local   18690260
    numa_other   0
        protection: (0, 0, 0, 0)
  pagesets
    cpu: 0
              count: 69
              high:  186
              batch: 31

vm stats threshold: 6
all_unreclaimable: 0
prev_priority: 12
start_pfn: 4096

[root@builder ~]# cat /proc/slabinfo
slabinfo - version: 2.1

# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
rpc_inode_cache       39     39    832   39    8 : tunables    0    0    0 : slabdata      1      1      0
nf_conntrack_expect      0      0    240   34    2 : tunables    0    0    0 : slabdata      0      0      0
UDPv6                 34     34    960   34    8 : tunables    0    0    0 : slabdata      1      1      0
TCPv6                 18     18   1792   18    8 : tunables    0    0    0 : slabdata      1      1      0
kmalloc_dma-512       32     32    512   32    4 : tunables    0    0    0 : slabdata      1      1      0
dm_snap_pending_exception    144    144    112   36    1 : tunables    0    0    0 : slabdata      4      4      0
kcopyd_job             0      0    360   45    4 : tunables    0    0    0 : slabdata      0      0      0
dm_uevent              0      0   2608   12    8 : tunables    0    0    0 : slabdata      0      0      0
ext3_inode_cache     387   1554    768   42    8 : tunables    0    0    0 : slabdata     37     37      0
ext3_xattr            46     46     88   46    1 : tunables    0    0    0 : slabdata      1      1      0
journal_handle       170    170     24  170    1 : tunables    0    0    0 : slabdata      1      1      0
journal_head          42     42     96   42    1 : tunables    0    0    0 : slabdata      1      1      0
revoke_table         256    256     16  256    1 : tunables    0    0    0 : slabdata      1      1      0
revoke_record        128    128     32  128    1 : tunables    0    0    0 : slabdata      1      1      0
cfq_io_context        44     48    168   24    1 : tunables    0    0    0 : slabdata      2      2      0
mqueue_inode_cache     36     36    896   36    8 : tunables    0    0    0 : slabdata      1      1      0
isofs_inode_cache      0      0    616   26    4 : tunables    0    0    0 : slabdata      0      0      0
hugetlbfs_inode_cache     28     28    584   28    4 : tunables    0    0    0 : slabdata      1      1      0
dquot                  0      0    256   32    2 : tunables    0    0    0 : slabdata      0      0      0
inotify_event_cache    612    612     40  102    1 : tunables    0    0    0 : slabdata      6      6      0
fasync_cache      313798 313820     24  170    1 : tunables    0    0    0 : slabdata   1846   1846      0
shmem_inode_cache    735    738    792   41    8 : tunables    0    0    0 : slabdata     18     18      0
pid_namespace          0      0   2104   15    8 : tunables    0    0    0 : slabdata      0      0      0
nsproxy                0      0     56   73    1 : tunables    0    0    0 : slabdata      0      0      0
UNIX                  92     92    704   46    8 : tunables    0    0    0 : slabdata      2      2      0
xfrm_dst_cache         0      0    384   42    4 : tunables    0    0    0 : slabdata      0      0      0
ip_dst_cache          51     75    320   25    2 : tunables    0    0    0 : slabdata      3      3      0
TCP                   19     19   1664   19    8 : tunables    0    0    0 : slabdata      1      1      0
blkdev_integrity       0      0    120   34    1 : tunables    0    0    0 : slabdata      0      0      0
blkdev_queue          34     34   1824   17    8 : tunables    0    0    0 : slabdata      2      2      0
blkdev_requests       38     52    304   26    2 : tunables    0    0    0 : slabdata      2      2      0
sock_inode_cache     138    138    704   46    8 : tunables    0    0    0 : slabdata      3      3      0
file_lock_cache       42     42    192   42    2 : tunables    0    0    0 : slabdata      1      1      0
taskstats             26     26    312   26    2 : tunables    0    0    0 : slabdata      1      1      0
proc_inode_cache      90    162    600   27    4 : tunables    0    0    0 : slabdata      6      6      0
sigqueue              25     25    160   25    1 : tunables    0    0    0 : slabdata      1      1      0
radix_tree_node      623   2581    560   29    4 : tunables    0    0    0 : slabdata     89     89      0
bdev_cache            42     42    768   42    8 : tunables    0    0    0 : slabdata      1      1      0
sysfs_dir_cache     7084   7089     80   51    1 : tunables    0    0    0 : slabdata    139    139      0
inode_cache         1505   1708    568   28    4 : tunables    0    0    0 : slabdata     61     61      0
dentry              2555   4485    208   39    2 : tunables    0    0    0 : slabdata    115    115      0
avc_node            1735   2128     72   56    1 : tunables    0    0    0 : slabdata     38     38      0
buffer_head         1583   5472    112   36    1 : tunables    0    0    0 : slabdata    152    152      0
mm_struct             75     78    832   39    8 : tunables    0    0    0 : slabdata      2      2      0
vm_area_struct      2223   2438    176   46    2 : tunables    0    0    0 : slabdata     53     53      0
files_cache           78     84    768   42    8 : tunables    0    0    0 : slabdata      2      2      0
signal_cache         105    108    896   36    8 : tunables    0    0    0 : slabdata      3      3      0
sighand_cache         85     90   2112   15    8 : tunables    0    0    0 : slabdata      6      6      0
task_struct          141    145   5840    5    8 : tunables    0    0    0 : slabdata     29     29      0
anon_vma             741    768     32  128    1 : tunables    0    0    0 : slabdata      6      6      0
shared_policy_node     85     85     48   85    1 : tunables    0    0    0 : slabdata      1      1      0
numa_policy           56     60    136   30    1 : tunables    0    0    0 : slabdata      2      2      0
idr_layer_cache      269    270    536   30    4 : tunables    0    0    0 : slabdata      9      9      0
kmalloc-4096         247    248   4096    8    8 : tunables    0    0    0 : slabdata     31     31      0
kmalloc-2048         345    352   2048   16    8 : tunables    0    0    0 : slabdata     22     22      0
kmalloc-1024         396    416   1024   32    8 : tunables    0    0    0 : slabdata     13     13      0
kmalloc-512          297    320    512   32    4 : tunables    0    0    0 : slabdata     10     10      0
kmalloc-256          985    992    256   32    2 : tunables    0    0    0 : slabdata     31     31      0
Quoted 16 lines
kmalloc-128         1899   2016    128   32    1 : tunables    0    0    0 : slabdata     63     63      0
kmalloc-64          6795   9600     64   64    1 : tunables    0    0    0 : slabdata    150    150      0
kmalloc-32         20735  20736     32  128    1 : tunables    0    0    0 : slabdata    162    162      0
kmalloc-16        138778 139264     16  256    1 : tunables    0    0    0 : slabdata    544    544      0
kmalloc-8           8190   8192      8  512    1 : tunables    0    0    0 : slabdata     16     16      0
kmalloc-192          972   1050    192   42    2 : tunables    0    0    0 : slabdata     25     25      0
kmalloc-96          2815   2856     96   42    1 : tunables    0    0    0 : slabdata     68     68      0
kmem_cache_node        0      0     64   64    1 : tunables    0    0    0 : slabdata      0      0      0
Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#17 lore raw
Quoted 4 lines · On Mon, 9 Mar 2009 22:22:41 +0800 Wu Fengguang <[email protected]> wrote:

Thanks for the data! Now it seems that some pages are totally missing from bootmem or slabs or page cache or any application consumptions...

So it isn't just me that's blind. That's something I guess. :)

Quoted 5 lines

Will searching through /proc/kpageflags for reserved pages help identify the problem?

Oh kpageflags_read() does not include support for PG_reserved:

I can probably hack together something that outputs the served pages. Anything else that is of interest?

Quoted 4 lines
Quoted 1 line

DirectMap2M: 18446744073709551613

This field looks weird.

Sorry, red herring. I'm in the middle of a bisect and that particular old bug happened to surface. It was not present with the releases 2.6.27.

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#18 lore raw
Quoted 10 lines · Pierre Ossman
Quoted 4 lines · On Mon, 9 Mar 2009 22:22:41 +0800 Wu Fengguang <[email protected]> wrote:

Thanks for the data! Now it seems that some pages are totally missing from bootmem or slabs or page cache or any application consumptions...

So it isn't just me that's blind. That's something I guess. :)

Quoted 8 lines
Quoted 5 lines

Will searching through /proc/kpageflags for reserved pages help identify the problem?

Oh kpageflags_read() does not include support for PG_reserved:

I can probably hack together something that outputs the served pages. Anything else that is of interest?

Sure, Matt Mackall provides some example scripts for interpreting the kpageflags file:

http://selenic.com/repo/pagemap/

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

DirectMap2M: 18446744073709551613

This field looks weird.

Sorry, red herring. I'm in the middle of a bisect and that particular old bug happened to surface. It was not present with the releases 2.6.27.

That's OK.

        pgfault 25624481
        pgmajfault 2490
        pgrefill_dma 8144
        pgrefill_dma32 103508
        pgsteal_dma 4503
        pgsteal_dma32 179395
        pgscan_kswapd_dma 4999
        pgscan_kswapd_dma32 180546
        pgscan_direct_dma32 384
        slabs_scanned 153856

The above vmstat numbers are a bit large, maybe it's not a fresh booted system?

Thanks,
Fengguang

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#19 lore raw
Quoted 12 lines · On Tue, 10 Mar 2009 10:41:35 +0800 Wu Fengguang <[email protected]> wrote:
        pgfault 25624481
        pgmajfault 2490
        pgrefill_dma 8144
        pgrefill_dma32 103508
        pgsteal_dma 4503
        pgsteal_dma32 179395
        pgscan_kswapd_dma 4999
        pgscan_kswapd_dma32 180546
        pgscan_direct_dma32 384
        slabs_scanned 153856
Quoted 2 lines

The above vmstat numbers are a bit large, maybe it's not a fresh booted system?

Probably not. I just grabbed those stats as it was compiling the next kernel. It takes two hours, so I'm trying to do as many things in parallel as once. :/

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#20 lore raw
In reply to Wu Fengguang

Hi Pierre,

Quoted 11 lines · Wu Fengguang
Quoted 10 lines · Pierre Ossman
Quoted 4 lines · On Mon, 9 Mar 2009 22:22:41 +0800 Wu Fengguang <[email protected]> wrote:

Thanks for the data! Now it seems that some pages are totally missing from bootmem or slabs or page cache or any application consumptions...

So it isn't just me that's blind. That's something I guess. :)

Quoted 8 lines
Quoted 8 lines
Quoted 5 lines

Will searching through /proc/kpageflags for reserved pages help identify the problem?

Oh kpageflags_read() does not include support for PG_reserved:

I can probably hack together something that outputs the served pages. Anything else that is of interest?

Here is the initial patch and tool for finding the missing pages.

In the following example, the pages with no flags set is kind of too many (1816MB), but hopefully your missing pages will have PG_reserved or other flags set ;-)

# ./page-types
L:locked E:error R:referenced U:uptodate D:dirty L:lru A:active S:slab W:writeback x:reclaim B:buddy r:reserved c:swapcache b:swapbacked
 flags        symbolic-flags    page-count            MB
0x0000        ______________        464967          1816
0x0004        __R___________             1             0
0x0008        ___U__________             2             0
0x0014        __R_D_________             5             0
0x0020        _____L________             1             0
0x0028        ___U_L________          5956            23
0x002c        __RU_L________          5415            21
0x0038        ___UDL________             7             0
0x0068        ___U_LA_______           520             2
0x006c        __RU_LA_______          2083             8
0x0080        _______S______         10820            42
0x0228        ___U_L___x____           104             0
0x022c        __RU_L___x____            52             0
0x0268        ___U_LA__x____            22             0
0x026c        __RU_LA__x____            95             0
0x0400        __________B___           477             1
0x0800        ___________r__         18734            73
0x2008        ___U_________b             9             0
0x2068        ___U_LA______b          4644            18
0x206c        __RU_LA______b            33             0
0x2078        ___UDLA______b             4             0
0x207c        __RUDLA______b            17             0

total 513968 2007

Thanks,
Fengguang

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/errno.h>
#include <sys/fcntl.h>

/* copied from kpageflags_read() */
#define KPF_LOCKED 0
#define KPF_ERROR 1
#define KPF_REFERENCED 2
#define KPF_UPTODATE 3
#define KPF_DIRTY 4
#define KPF_LRU 5
#define KPF_ACTIVE 6
#define KPF_SLAB 7
#define KPF_WRITEBACK 8
#define KPF_RECLAIM 9
#define KPF_BUDDY 10
#define KPF_RESERVED 11
#define KPF_SWAPCACHE 12
#define KPF_SWAPBACKED 13

#define KPF_NUM 14
#define KPF_BYTES 8

#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

static char *page_flag_names[] = {
	[KPF_LOCKED]		= "L:locked",
	[KPF_ERROR]		= "E:error",
	[KPF_REFERENCED]	= "R:referenced",
	[KPF_UPTODATE]		= "U:uptodate",
	[KPF_DIRTY]		= "D:dirty",
	[KPF_LRU]		= "L:lru",
	[KPF_ACTIVE]		= "A:active",
	[KPF_SLAB]		= "S:slab",
	[KPF_WRITEBACK]		= "W:writeback",
	[KPF_RECLAIM]		= "x:reclaim",
	[KPF_BUDDY]		= "B:buddy",
	[KPF_RESERVED]		= "r:reserved",
	[KPF_SWAPBACKED]	= "b:swapbacked",
	[KPF_SWAPCACHE]		= "c:swapcache",
};

static unsigned long page_count[(1 << KPF_NUM)];
static unsigned long nr_pages;
static uint64_t kpageflags[KPF_BYTES * (8<<20)];

char *page_flag_name(uint64_t flags, char *buf)

{
	int i;

	for (i = 0; i < ARRAY_SIZE(page_flag_names); i++)
		buf[i] = (flags & (1 << i)) ? page_flag_names[i][0] : '_';

	return buf;
}

static unsigned long pages2mb(unsigned long pages)

{
	return (pages * getpagesize()) >> 20;
}

int main(int argc, char *argv[])

{
	static char kpageflags_name[] = "/proc/kpageflags";
	static char buf[64];
	unsigned long i;
	uint64_t flags;
	int fd;

	fd = open(kpageflags_name, O_RDONLY);
	if (fd < 0) {
		fprintf(stderr, "%s: cannot open `%s': %s\n",
				argv[0], kpageflags_name, strerror(errno));
		exit(1);
	}

	nr_pages = read(fd, kpageflags, sizeof(kpageflags));
	if (nr_pages <= 0) {
		fprintf(stderr, "%s: cannot read `%s': %s\n",
				argv[0], kpageflags_name, strerror(errno));
		exit(2);
	}
	if (nr_pages % KPF_BYTES != 0) {
		fprintf(stderr, "%s: partial read: %lu bytes\n",
				argv[0], nr_pages);
		exit(3);
	}
	nr_pages = nr_pages / KPF_BYTES;

	for (i = 0; i < nr_pages; i++) {
		flags = kpageflags[i];
		if (flags == 0x40000)
			flags = ARRAY_SIZE(page_count) - 1;
		if (flags >= ARRAY_SIZE(page_count)) {
			fprintf(stderr, "%s: flags overflow: 0x%lx > 0x%lx\n",
					argv[0], flags, ARRAY_SIZE(page_count));
			exit(4);
		}
		page_count[flags]++;
	}

	for (i = 0; i < ARRAY_SIZE(page_flag_names); i++) {
		printf("%s ", page_flag_names[i]);
	}

	printf("\n\n flags\t      symbolic-flags\tpage-count\t      MB\n");
	for (i = 0; i < ARRAY_SIZE(page_count); i++) {
		if (page_count[i])
			printf("0x%04lx\t%20s\t%10lu\t%8lu\n",
				i,
				page_flag_name(i, buf),
				page_count[i],
				pages2mb(page_count[i]));
	}

	printf("\n total\t\t\t\t%10lu\t%8lu\n",
			nr_pages, pages2mb(nr_pages));

	return 0;
}
fs/proc/page.c +8 -2
index 2d13451..6022f1e 100644
@@ -79,8 +79,11 @@ static const struct file_operations proc_kpagecount_operations = {
 #define KPF_WRITEBACK  8
 #define KPF_RECLAIM    9
 #define KPF_BUDDY     10
+#define KPF_RESERVED  11
+#define KPF_SWAPCACHE 12
+#define KPF_SWAPBACKED 13
 
-#define kpf_copy_bit(flags, srcpos, dstpos) (((flags >> srcpos) & 1) << dstpos)
+#define kpf_copy_bit(flags, dstpos, srcpos) (((flags >> srcpos) & 1) << dstpos)
 
 static ssize_t kpageflags_read(struct file *file, char __user *buf,
 			     size_t count, loff_t *ppos)
@@ -117,7 +120,10 @@ static ssize_t kpageflags_read(struct file *file, char __user *buf,
 			kpf_copy_bit(kflags, KPF_SLAB, PG_slab) |
 			kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback) |
 			kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim) |
-			kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy);
+			kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy) |
+			kpf_copy_bit(kflags, KPF_SWAPCACHE, PG_swapcache) |
+			kpf_copy_bit(kflags, KPF_SWAPBACKED, PG_swapbacked) |
+			kpf_copy_bit(kflags, KPF_RESERVED, PG_reserved);
 
 		if (put_user(uflags, out++)) {
 			ret = -EFAULT;
#21 lore raw
Quoted 10 lines · On Tue, 10 Mar 2009 16:19:17 +0800 Wu Fengguang <[email protected]> wrote:

Here is the initial patch and tool for finding the missing pages.

In the following example, the pages with no flags set is kind of too many (1816MB), but hopefully your missing pages will have PG_reserved or other flags set ;-)

# ./page-types
L:locked E:error R:referenced U:uptodate D:dirty L:lru A:active S:slab W:writeback x:reclaim B:buddy r:reserved c:swapcache b:swapbacked

Thanks. I'll have a look in a bit. Right now I'm very close to a complete bisect. It is just ftrace commits left though, so I'm somewhat sceptical that it is correct. ftrace isn't even turned on in the kernels I've been testing.

The remaining commits are ec1bb60bb..6712e299.

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#22 lore raw
Quoted 14 lines · Pierre Ossman
Quoted 10 lines · On Tue, 10 Mar 2009 16:19:17 +0800 Wu Fengguang <[email protected]> wrote:

Here is the initial patch and tool for finding the missing pages.

In the following example, the pages with no flags set is kind of too many (1816MB), but hopefully your missing pages will have PG_reserved or other flags set ;-)

# ./page-types
L:locked E:error R:referenced U:uptodate D:dirty L:lru A:active S:slab W:writeback x:reclaim B:buddy r:reserved c:swapcache b:swapbacked
Quoted 6 lines

Thanks. I'll have a look in a bit. Right now I'm very close to a complete bisect. It is just ftrace commits left though, so I'm somewhat sceptical that it is correct. ftrace isn't even turned on in the kernels I've been testing.

The remaining commits are ec1bb60bb..6712e299.

And here's my progress, some more page flags are introduced:

# ./page-types
  flags page-count       MB    symbolic-flags    long-symbolic-flags
0x00000       3978       15  __________________  
0x00004          1        0  __R_______________  referenced
0x00014          5        0  __R_D_____________  referenced,dirty
0x00020          2        0  _____l____________  lru
0x00028       8835       34  ___U_l____________  uptodate,lru
0x0002c       9588       37  __RU_l____________  referenced,uptodate,lru
0x00068       1031        4  ___U_lA___________  uptodate,lru,active
0x0006c       3032       11  __RU_lA___________  referenced,uptodate,lru,active
0x00080      11001       42  _______S__________  slab
0x00228        140        0  ___U_l___x________  uptodate,lru,reclaim
0x0022c         79        0  __RU_l___x________  referenced,uptodate,lru,reclaim
0x00268         43        0  ___U_lA__x________  uptodate,lru,active,reclaim
0x0026c        110        0  __RU_lA__x________  referenced,uptodate,lru,active,reclaim
0x00400       1102        4  __________B_______  buddy
0x00800      18735       73  ___________r______  reserved
0x02008         13        0  ___U_________b____  uptodate,swapbacked
0x02068       9371       36  ___U_lA______b____  uptodate,lru,active,swapbacked
0x0206c       1339        5  __RU_lA______b____  referenced,uptodate,lru,active,swapbacked
0x02078         21        0  ___UDlA______b____  uptodate,dirty,lru,active,swapbacked
0x0207c         17        0  __RUDlA______b____  referenced,uptodate,dirty,lru,active,swapbacked
0x20000     445525     1740  _________________n  noflags
  total     513968     2007

Thanks,
Fengguang

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/errno.h>
#include <sys/fcntl.h>

/* copied from kpageflags_read() */

enum {
	KPF_LOCKED,	/*  0 */
	KPF_ERROR,	/*  1 */
	KPF_REFERENCED,	/*  2 */
	KPF_UPTODATE,	/*  3 */
	KPF_DIRTY,	/*  4 */
	KPF_LRU,	/*  5 */
	KPF_ACTIVE,	/*  6 */
	KPF_SLAB,	/*  7 */
	KPF_WRITEBACK,	/*  8 */
	KPF_RECLAIM,	/*  9 */
	KPF_BUDDY,	/* 10 */
	KPF_RESERVED,	/* 11 */
	KPF_SWAPCACHE,	/* 12 */
	KPF_SWAPBACKED,	/* 13 */
        KPF_PRIVATE,    /* 14 */
        KPF_PRIVATE2,   /* 15 */
        KPF_NOPAGE,     /* 16 */
        KPF_NOFLAGS,    /* 17 */
	KPF_NUM
};

#define KPF_BYTES 8

#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

static char *page_flag_names[] = {
	[KPF_LOCKED]		= "L:locked",
	[KPF_ERROR]		= "E:error",
	[KPF_REFERENCED]	= "R:referenced",
	[KPF_UPTODATE]		= "U:uptodate",
	[KPF_DIRTY]		= "D:dirty",
	[KPF_LRU]		= "l:lru",
	[KPF_ACTIVE]		= "A:active",
	[KPF_SLAB]		= "S:slab",
	[KPF_WRITEBACK]		= "W:writeback",
	[KPF_RECLAIM]		= "x:reclaim",
	[KPF_BUDDY]		= "B:buddy",
	[KPF_RESERVED]		= "r:reserved",
	[KPF_SWAPBACKED]	= "b:swapbacked",
	[KPF_SWAPCACHE]		= "c:swapcache",
	[KPF_PRIVATE]		= "P:private",
	[KPF_PRIVATE2]		= "p:private_2",
	[KPF_NOPAGE]		= "N:nopage",
	[KPF_NOFLAGS]		= "n:noflags",
};

static unsigned long page_count[(1 << KPF_NUM)];
static unsigned long nr_pages;
static uint64_t kpageflags[KPF_BYTES * (8<<20)];

char *page_flag_name(uint64_t flags)

{
	int i;
	static char buf[64];

	for (i = 0; i < ARRAY_SIZE(page_flag_names); i++)
		buf[i] = (flags & (1 << i)) ? page_flag_names[i][0] : '_';

	return buf;
}

char *page_flag_longname(uint64_t flags)

{
	int i, n;
	static char buf[1024];

	for (i = 0, n = 0; i < ARRAY_SIZE(page_flag_names); i++)
		if (flags & (1<<i))
		       n += snprintf(buf + n, sizeof(buf) - n, "%s,",
				       page_flag_names[i] + 2);
	if (n)
		n--;
	buf[n] = '\0';

	return buf;
}

static unsigned long pages2mb(unsigned long pages)

{
	return (pages * getpagesize()) >> 20;
}

int main(int argc, char *argv[])

{
	static char kpageflags_name[] = "/proc/kpageflags";
	unsigned long i;
	uint64_t flags;
	int fd;

	fd = open(kpageflags_name, O_RDONLY);
	if (fd < 0) {
		fprintf(stderr, "%s: cannot open `%s': %s\n",
				argv[0], kpageflags_name, strerror(errno));
		exit(1);
	}

	nr_pages = read(fd, kpageflags, sizeof(kpageflags));
	if (nr_pages <= 0) {
		fprintf(stderr, "%s: cannot read `%s': %s\n",
				argv[0], kpageflags_name, strerror(errno));
		exit(2);
	}
	if (nr_pages % KPF_BYTES != 0) {
		fprintf(stderr, "%s: partial read: %lu bytes\n",
				argv[0], nr_pages);
		exit(3);
	}
	nr_pages = nr_pages / KPF_BYTES;

	for (i = 0; i < nr_pages; i++) {
		flags = kpageflags[i];
		if (flags == 0x40000)
			flags = ARRAY_SIZE(page_count) - 1;
		if (flags >= ARRAY_SIZE(page_count)) {
			fprintf(stderr, "%s: flags overflow: 0x%lx > 0x%lx\n",
					argv[0], flags, ARRAY_SIZE(page_count));
			exit(4);
		}
		page_count[flags]++;
	}
#if 0
	for (i = 0; i < ARRAY_SIZE(page_flag_names); i++) {
		printf("%s ", page_flag_names[i]);
	}

#endif

	printf("  flags\tpage-count       MB    symbolic-flags    long-symbolic-flags\n");
	for (i = 0; i < ARRAY_SIZE(page_count); i++) {
		if (page_count[i])
			printf("0x%05lx\t%10lu %8lu  %s  %s\n",
				i,
				page_count[i],
				pages2mb(page_count[i]),
				page_flag_name(i),
				page_flag_longname(i));
	}

	printf("  total\t%10lu %8lu\n",
			nr_pages, pages2mb(nr_pages));

	return 0;
}
---
 fs/proc/page.c |   88 +++++++++++++++++++++++++++++------------------
 1 file changed, 56 insertions(+), 32 deletions(-)
fs/proc/page.c +56 -32
@@ -68,19 +68,60 @@ static const struct file_operations proc
 
 /* These macros are used to decouple internal flags from exported ones */
 
-#define KPF_LOCKED     0
-#define KPF_ERROR      1
-#define KPF_REFERENCED 2
-#define KPF_UPTODATE   3
-#define KPF_DIRTY      4
-#define KPF_LRU        5
-#define KPF_ACTIVE     6
-#define KPF_SLAB       7
-#define KPF_WRITEBACK  8
-#define KPF_RECLAIM    9
-#define KPF_BUDDY     10
+enum {
+	KPF_LOCKED,	/*  0 */
+	KPF_ERROR,	/*  1 */
+	KPF_REFERENCED,	/*  2 */
+	KPF_UPTODATE,	/*  3 */
+	KPF_DIRTY,	/*  4 */
+	KPF_LRU,	/*  5 */
+	KPF_ACTIVE,	/*  6 */
+	KPF_SLAB,	/*  7 */
+	KPF_WRITEBACK,	/*  8 */
+	KPF_RECLAIM,	/*  9 */
+	KPF_BUDDY,	/* 10 */
+	KPF_RESERVED,	/* 11 */
+	KPF_SWAPCACHE,	/* 12 */
+	KPF_SWAPBACKED,	/* 13 */
+	KPF_PRIVATE,	/* 14 */
+	KPF_PRIVATE2,	/* 15 */
+	KPF_NOPAGE,	/* 16 */
+	KPF_NOFLAGS,	/* 17 */
+	KPF_NUM
+};
+
+#define PAGE_FLAGS_MASK	((1 << __NR_PAGEFLAGS) - 1)
+
+#define kpf_copy_bit(flags, dstpos, srcpos) (((flags >> srcpos) & 1) << dstpos)
 
-#define kpf_copy_bit(flags, srcpos, dstpos) (((flags >> srcpos) & 1) << dstpos)
+u64 get_uflags(struct page *page)
+{
+	unsigned long kflags;
+
+	if (!page)
+		return (1 << KPF_NOPAGE);
+
+	kflags = page->flags;
+	if ((kflags & PAGE_FLAGS_MASK) == 0)
+		return (1 << KPF_NOFLAGS);
+
+	return kpf_copy_bit(kflags, KPF_LOCKED,     PG_locked)	   |
+	       kpf_copy_bit(kflags, KPF_ERROR,	    PG_error)	   |
+	       kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced) |
+	       kpf_copy_bit(kflags, KPF_UPTODATE,   PG_uptodate)   |
+	       kpf_copy_bit(kflags, KPF_DIRTY,	    PG_dirty)	   |
+	       kpf_copy_bit(kflags, KPF_LRU,	    PG_lru)	   |
+	       kpf_copy_bit(kflags, KPF_ACTIVE,     PG_active)	   |
+	       kpf_copy_bit(kflags, KPF_SLAB,	    PG_slab)	   |
+	       kpf_copy_bit(kflags, KPF_WRITEBACK,  PG_writeback)  |
+	       kpf_copy_bit(kflags, KPF_RECLAIM,    PG_reclaim)	   |
+	       kpf_copy_bit(kflags, KPF_BUDDY,	    PG_buddy)	   |
+	       kpf_copy_bit(kflags, KPF_SWAPCACHE,  PG_swapcache)  |
+	       kpf_copy_bit(kflags, KPF_SWAPBACKED, PG_swapbacked) |
+	       kpf_copy_bit(kflags, KPF_PRIVATE,    PG_private)    |
+	       kpf_copy_bit(kflags, KPF_PRIVATE2,   PG_private_2)  |
+	       kpf_copy_bit(kflags, KPF_RESERVED,   PG_reserved);
+};
 
 static ssize_t kpageflags_read(struct file *file, char __user *buf,
 			     size_t count, loff_t *ppos)
@@ -90,7 +131,6 @@ static ssize_t kpageflags_read(struct fi
 	unsigned long src = *ppos;
 	unsigned long pfn;
 	ssize_t ret = 0;
-	u64 kflags, uflags;
 
 	pfn = src / KPMSIZE;
 	count = min_t(unsigned long, count, (max_pfn * KPMSIZE) - src);
@@ -98,32 +138,16 @@ static ssize_t kpageflags_read(struct fi
 		return -EINVAL;
 
 	while (count > 0) {
-		ppage = NULL;
 		if (pfn_valid(pfn))
 			ppage = pfn_to_page(pfn);
-		pfn++;
-		if (!ppage)
-			kflags = 0;
 		else
-			kflags = ppage->flags;
-
-		uflags = kpf_copy_bit(kflags, KPF_LOCKED, PG_locked) |
-			kpf_copy_bit(kflags, KPF_ERROR, PG_error) |
-			kpf_copy_bit(kflags, KPF_REFERENCED, PG_referenced) |
-			kpf_copy_bit(kflags, KPF_UPTODATE, PG_uptodate) |
-			kpf_copy_bit(kflags, KPF_DIRTY, PG_dirty) |
-			kpf_copy_bit(kflags, KPF_LRU, PG_lru) |
-			kpf_copy_bit(kflags, KPF_ACTIVE, PG_active) |
-			kpf_copy_bit(kflags, KPF_SLAB, PG_slab) |
-			kpf_copy_bit(kflags, KPF_WRITEBACK, PG_writeback) |
-			kpf_copy_bit(kflags, KPF_RECLAIM, PG_reclaim) |
-			kpf_copy_bit(kflags, KPF_BUDDY, PG_buddy);
+			ppage = NULL;
+		pfn++;
 
-		if (put_user(uflags, out++)) {
+		if (put_user(get_uflags(ppage), out++)) {
 			ret = -EFAULT;
 			break;
 		}
-
 		count -= KPMSIZE;
 	}
 
#23 lore raw
Quoted 15 lines · Wu Fengguang
Quoted 14 lines · Pierre Ossman
Quoted 10 lines · On Tue, 10 Mar 2009 16:19:17 +0800 Wu Fengguang <[email protected]> wrote:

Here is the initial patch and tool for finding the missing pages.

In the following example, the pages with no flags set is kind of too many (1816MB), but hopefully your missing pages will have PG_reserved or other flags set ;-)

# ./page-types
L:locked E:error R:referenced U:uptodate D:dirty L:lru A:active S:slab W:writeback x:reclaim B:buddy r:reserved c:swapcache b:swapbacked
Quoted 6 lines
Quoted 6 lines

Thanks. I'll have a look in a bit. Right now I'm very close to a complete bisect. It is just ftrace commits left though, so I'm somewhat sceptical that it is correct. ftrace isn't even turned on in the kernels I've been testing.

The remaining commits are ec1bb60bb..6712e299.

Another tool to show the page locations with specified flags:

# ./page-areas 0x20000 | head
    offset      len         KB
        11        1        4KB
        13        3       12KB
        17        7       28KB
        25        1        4KB
        31        1        4KB
        33       31      124KB
        65       63      252KB
       129       15       60KB
       145        7       28KB

If we run eatmem or the following commands to take up free memory, the missing pages will show up :-)

dd if=/dev/zero of=/tmp/s bs=1M count=1 seek=1024 cp /tmp/s /dev/null

Thanks,
Fengguang

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/errno.h>
#include <sys/fcntl.h>

/* copied from kpageflags_read() */

enum {
	KPF_LOCKED,	/*  0 */
	KPF_ERROR,	/*  1 */
	KPF_REFERENCED,	/*  2 */
	KPF_UPTODATE,	/*  3 */
	KPF_DIRTY,	/*  4 */
	KPF_LRU,	/*  5 */
	KPF_ACTIVE,	/*  6 */
	KPF_SLAB,	/*  7 */
	KPF_WRITEBACK,	/*  8 */
	KPF_RECLAIM,	/*  9 */
	KPF_BUDDY,	/* 10 */
	KPF_RESERVED,	/* 11 */
	KPF_SWAPCACHE,	/* 12 */
	KPF_SWAPBACKED,	/* 13 */
        KPF_PRIVATE,    /* 14 */
        KPF_PRIVATE2,   /* 15 */
        KPF_NOPAGE,     /* 16 */
        KPF_NOFLAGS,    /* 17 */
	KPF_NUM
};

#define KPF_BYTES 8

#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

static char *page_flag_names[] = {
	[KPF_LOCKED]		= "L:locked",
	[KPF_ERROR]		= "E:error",
	[KPF_REFERENCED]	= "R:referenced",
	[KPF_UPTODATE]		= "U:uptodate",
	[KPF_DIRTY]		= "D:dirty",
	[KPF_LRU]		= "l:lru",
	[KPF_ACTIVE]		= "A:active",
	[KPF_SLAB]		= "S:slab",
	[KPF_WRITEBACK]		= "W:writeback",
	[KPF_RECLAIM]		= "x:reclaim",
	[KPF_BUDDY]		= "B:buddy",
	[KPF_RESERVED]		= "r:reserved",
	[KPF_SWAPBACKED]	= "b:swapbacked",
	[KPF_SWAPCACHE]		= "c:swapcache",
	[KPF_PRIVATE]		= "P:private",
	[KPF_PRIVATE2]		= "p:private_2",
	[KPF_NOPAGE]		= "N:nopage",
	[KPF_NOFLAGS]		= "n:noflags",
};

static unsigned long page_count[(1 << KPF_NUM)];
static unsigned long nr_pages;
static uint64_t kpageflags[KPF_BYTES * (8<<20)];

char *page_flag_name(uint64_t flags)

{
	int i;
	static char buf[64];

	for (i = 0; i < ARRAY_SIZE(page_flag_names); i++)
		buf[i] = (flags & (1 << i)) ? page_flag_names[i][0] : '_';

	return buf;
}

char *page_flag_longname(uint64_t flags)

{
	int i, n;
	static char buf[1024];

	for (i = 0, n = 0; i < ARRAY_SIZE(page_flag_names); i++)
		if (flags & (1<<i))
		       n += snprintf(buf + n, sizeof(buf) - n, "%s,",
				       page_flag_names[i] + 2);
	if (n)
		n--;
	buf[n] = '\0';

	return buf;
}

static unsigned long pages2kb(unsigned long pages)

{
	return (pages * getpagesize()) >> 10;
}

static void add_index(unsigned long index)

{
	static unsigned long offset, len;

	if (index == offset + len)
		len++;
	else {
		if (len)
			printf("%10lu %8lu %8luKB\n", offset, len, pages2kb(len));
		offset = index;
		len = 1;
	}
}

static void usage(const char *prog)

{
	printf("Usage: %s page_flags\n", prog);
}

int main(int argc, char *argv[])

{
	static char kpageflags_name[] = "/proc/kpageflags";
	unsigned long match_flags;
	unsigned long i;
	int fd;

	if (argc < 2) {
		usage(argv[0]);
		exit(1);
	}

	match_flags = strtol(argv[1], 0, 16);
	/* printf("pages with flags 0x%lx:\n", match_flags); */

	fd = open(kpageflags_name, O_RDONLY);
	if (fd < 0) {
		perror(kpageflags_name);
		exit(1);
	}

	nr_pages = read(fd, kpageflags, sizeof(kpageflags));
	if (nr_pages <= 0) {
		perror(kpageflags_name);
		exit(2);
	}
	if (nr_pages % KPF_BYTES != 0) {
		fprintf(stderr, "%s: partial read: %lu bytes\n",
				argv[0], nr_pages);
		exit(3);
	}
	nr_pages = nr_pages / KPF_BYTES;

	printf("    offset      len         KB\n");
	for (i = 0; i < nr_pages; i++) {
		if ((kpageflags[i] & match_flags) == match_flags)
			add_index(i);
	}
	add_index(0);

	return 0;
}
#24 lore raw

My bisect has ran into a wall. I cannot run any of the intermediate kernels that are left. I could try reverting the commits one at a time, but I'll take a break and test your code here. Now we just have to wait for the kernel to compile. :)

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#25 lore raw
In reply to Wu Fengguang
Quoted 6 lines · On Tue, 10 Mar 2009 21:11:55 +0800 Wu Fengguang <[email protected]> wrote:

If we run eatmem or the following commands to take up free memory, the missing pages will show up :-)

dd if=/dev/zero of=/tmp/s bs=1M count=1 seek=1024 cp /tmp/s /dev/null

Not here, which now means I've "found" all of my missing 170 MB.

On 2.6.27, when I fill the page cache I still get over 90 MB left in "noflags":

0x20000 24394 95 _________________n noflags

The same thing with 2.6.26 almost completely drains it:

0x20000 3697 14 _________________n noflags

Another interesting data point is that those 80 MB always seem to be the exact same number of pages every boot.

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#26 lore raw
Quoted 15 lines · Pierre Ossman
Quoted 6 lines · On Tue, 10 Mar 2009 21:11:55 +0800 Wu Fengguang <[email protected]> wrote:

If we run eatmem or the following commands to take up free memory, the missing pages will show up :-)

dd if=/dev/zero of=/tmp/s bs=1M count=1 seek=1024 cp /tmp/s /dev/null

Not here, which now means I've "found" all of my missing 170 MB.

On 2.6.27, when I fill the page cache I still get over 90 MB left in "noflags":

Quoted 8 lines

0x20000 24394 95 _________________n noflags

The same thing with 2.6.26 almost completely drains it:

0x20000 3697 14 _________________n noflags

Another interesting data point is that those 80 MB always seem to be the exact same number of pages every boot.

This 80MB noflags pages together with the below 80MB lru pages are very close to the missing page numbers :-) Could you run the following commands on fresh booted 2.6.27 and post the output files? Thank you!

        dd if=/dev/zero of=/tmp/s bs=1M count=1 seek=1024
        cp /tmp/s /dev/null

        ./page-flags > flags
        ./page-areas =0x20000 > areas-noflags
        ./page-areas =0x00020 > areas-lru

The attached page-areas.c can do the above exact flags matching.

Quoted 10 lines

After that, a comparison shows that this row is in 2.6.27, but not 2.6.26:

0x00020 20576 80 _____l____________ lru

Unfortunately there are about 170 MB of missing memory, not 80. So we probably need to dig deeper. But does the above say anything to you?

I had to remove PG_swapbacked and PG_private2 as 2.6.26/2.6.27 didn't have those bits.

Ah sorry! I forgot to switch the tree back to 2.6.27 to run a test.

Thanks,
Fengguang

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/errno.h>
#include <sys/fcntl.h>

/* copied from kpageflags_read() */

enum {
	KPF_LOCKED,	/*  0 */
	KPF_ERROR,	/*  1 */
	KPF_REFERENCED,	/*  2 */
	KPF_UPTODATE,	/*  3 */
	KPF_DIRTY,	/*  4 */
	KPF_LRU,	/*  5 */
	KPF_ACTIVE,	/*  6 */
	KPF_SLAB,	/*  7 */
	KPF_WRITEBACK,	/*  8 */
	KPF_RECLAIM,	/*  9 */
	KPF_BUDDY,	/* 10 */
	KPF_RESERVED,	/* 11 */
	KPF_SWAPCACHE,	/* 12 */
	KPF_SWAPBACKED,	/* 13 */
        KPF_PRIVATE,    /* 14 */
        KPF_PRIVATE2,   /* 15 */
        KPF_NOPAGE,     /* 16 */
        KPF_NOFLAGS,    /* 17 */
	KPF_NUM
};

#define KPF_BYTES 8

#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

static char *page_flag_names[] = {
	[KPF_LOCKED]		= "L:locked",
	[KPF_ERROR]		= "E:error",
	[KPF_REFERENCED]	= "R:referenced",
	[KPF_UPTODATE]		= "U:uptodate",
	[KPF_DIRTY]		= "D:dirty",
	[KPF_LRU]		= "l:lru",
	[KPF_ACTIVE]		= "A:active",
	[KPF_SLAB]		= "S:slab",
	[KPF_WRITEBACK]		= "W:writeback",
	[KPF_RECLAIM]		= "x:reclaim",
	[KPF_BUDDY]		= "B:buddy",
	[KPF_RESERVED]		= "r:reserved",
	[KPF_SWAPBACKED]	= "b:swapbacked",
	[KPF_SWAPCACHE]		= "c:swapcache",
	[KPF_PRIVATE]		= "P:private",
	[KPF_PRIVATE2]		= "p:private_2",
	[KPF_NOPAGE]		= "N:nopage",
	[KPF_NOFLAGS]		= "n:noflags",
};

static unsigned long page_count[(1 << KPF_NUM)];
static unsigned long nr_pages;
static uint64_t kpageflags[KPF_BYTES * (8<<20)];

char *page_flag_name(uint64_t flags)

{
	int i;
	static char buf[64];

	for (i = 0; i < ARRAY_SIZE(page_flag_names); i++)
		buf[i] = (flags & (1 << i)) ? page_flag_names[i][0] : '_';

	return buf;
}

char *page_flag_longname(uint64_t flags)

{
	int i, n;
	static char buf[1024];

	for (i = 0, n = 0; i < ARRAY_SIZE(page_flag_names); i++)
		if (flags & (1<<i))
		       n += snprintf(buf + n, sizeof(buf) - n, "%s,",
				       page_flag_names[i] + 2);
	if (n)
		n--;
	buf[n] = '\0';

	return buf;
}

static unsigned long pages2kb(unsigned long pages)

{
	return (pages * getpagesize()) >> 10;
}

static void add_index(unsigned long index)

{
	static unsigned long offset, len;

	if (index == offset + len)
		len++;
	else {
		if (len)
			printf("%10lu %8lu %8luKB\n", offset, len, pages2kb(len));
		offset = index;
		len = 1;
	}
}

static void usage(const char *prog)

{
	printf("Usage: %s page_flags\n", prog);
}

int main(int argc, char *argv[])

{
	static char kpageflags_name[] = "/proc/kpageflags";
	unsigned long match_flags, match_exact;
	unsigned long i;
	char *p;
	int fd;

	if (argc < 2) {
		usage(argv[0]);
		exit(1);
	}

	match_exact = 0;
	p = argv[1];
	if (p[0] == '=') {
		match_exact = 1;
		p++;
	}
	match_flags = strtol(p, 0, 16);

	fd = open(kpageflags_name, O_RDONLY);
	if (fd < 0) {
		perror(kpageflags_name);
		exit(1);
	}

	nr_pages = read(fd, kpageflags, sizeof(kpageflags));
	if (nr_pages <= 0) {
		perror(kpageflags_name);
		exit(2);
	}
	if (nr_pages % KPF_BYTES != 0) {
		fprintf(stderr, "%s: partial read: %lu bytes\n",
				argv[0], nr_pages);
		exit(3);
	}
	nr_pages = nr_pages / KPF_BYTES;

	printf("    offset      len         KB\n");
	for (i = 0; i < nr_pages; i++) {
		if (!match_exact && ((kpageflags[i] & match_flags) == match_flags) ||
		    (match_exact && kpageflags[i] == match_flags))
			add_index(i);
	}
	add_index(0);

	return 0;
}

A message that is not in the archive (sent off-list or not yet received): [email protected]

#28 lore raw
Quoted 11 lines · Pierre Ossman
Quoted 8 lines · On Wed, 11 Mar 2009 09:37:40 +0800 Wu Fengguang <[email protected]> wrote:

This 80MB noflags pages together with the below 80MB lru pages are very close to the missing page numbers :-) Could you run the following commands on fresh booted 2.6.27 and post the output files? Thank you!

dd if=/dev/zero of=/tmp/s bs=1M count=1 seek=1024 cp /tmp/s /dev/null

Quoted 6 lines
Quoted 4 lines
        ./page-flags > flags
        ./page-areas =0x20000 > areas-noflags
        ./page-areas =0x00020 > areas-lru

Attached.

Thank you very much!

Quoted 1 line

I have to say, the patterns look very much like some kind of leak.

Wow it looks really interesting. The lru pages and noflags pages make perfect 1-page interleaved pattern...

Thanks,
Fengguang

areas-lru

Quoted 38 lines
    offset      len         KB
     86016        1        4KB
     86018        1        4KB
     86020        1        4KB
     86022        1        4KB
     86024        1        4KB
     86026        1        4KB
     86028        1        4KB
     86030        1        4KB
     86032        1        4KB
     86034        1        4KB
     86036        1        4KB
     86038        1        4KB
     86040        1        4KB
     86042        1        4KB
     86044        1        4KB
     86046        1        4KB
     86048        1        4KB
     86050        1        4KB
     86052        1        4KB
     86054        1        4KB
     86056        1        4KB
     86058        1        4KB
     86060        1        4KB
     86062        1        4KB
     86064        1        4KB
     86066        1        4KB
     86068        1        4KB
     86070        1        4KB
     86072        1        4KB
     86074        1        4KB
     86076        1        4KB
     86078        1        4KB
     86080        1        4KB
     86082        1        4KB
     86084        1        4KB
     86086        1        4KB
     86088        1        4KB
Quoted 8 lines
     86090        1        4KB
     86092        1        4KB
     86094        1        4KB
     86096        1        4KB
     86098        1        4KB
     86100        1        4KB
     86102        1        4KB
     86104        1        4KB

areas-noflags

Quoted 99 lines
     86017        1        4KB
     86019        1        4KB
     86021        1        4KB
     86023        1        4KB
     86025        1        4KB
     86027        1        4KB
     86029        1        4KB
     86031        1        4KB
     86033        1        4KB
     86035        1        4KB
     86037        1        4KB
     86039        1        4KB
     86041        1        4KB
     86043        1        4KB
     86045        1        4KB
     86047        1        4KB
     86049        1        4KB
     86051        1        4KB
     86053        1        4KB
     86055        1        4KB
     86057        1        4KB
     86059        1        4KB
     86061        1        4KB
     86063        1        4KB
     86065        1        4KB
     86067        1        4KB
     86069        1        4KB
     86071        1        4KB
     86073        1        4KB
     86075        1        4KB
     86077        1        4KB
     86079        1        4KB
     86081        1        4KB
     86083        1        4KB
     86085        1        4KB
     86087        1        4KB
     86089        1        4KB
     86091        1        4KB
     86093        1        4KB
     86095        1        4KB
     86097        1        4KB
     86099        1        4KB
     86101        1        4KB
     86103        1        4KB

flags page-count MB symbolic-flags long-symbolic-flags

0x00000	      1892        7  __________________  
0x00004	         1        0  __R_______________  referenced
0x00008	       454        1  ___U______________  uptodate
0x0000c	        94        0  __RU______________  referenced,uptodate
0x00020	     20576       80  _____l____________  lru
0x00028	       226        0  ___U_l____________  uptodate,lru
0x0002c	     67911      265  __RU_l____________  referenced,uptodate,lru
0x00068	      6621       25  ___U_lA___________  uptodate,lru,active
0x0006c	      1222        4  __RU_lA___________  referenced,uptodate,lru,active
0x00078	         1        0  ___UDlA___________  uptodate,dirty,lru,active
0x00080	      3523       13  _______S__________  slab
0x000c0	        55        0  ______AS__________  active,slab
0x00228	         5        0  ___U_l___x________  uptodate,lru,reclaim
0x0022c	         1        0  __RU_l___x________  referenced,uptodate,lru,reclaim
0x00268	        23        0  ___U_lA__x________  uptodate,lru,active,reclaim
0x0026c	        52        0  __RU_lA__x________  referenced,uptodate,lru,active,reclaim
0x00400	         9        0  __________B_______  buddy
0x00408	        60        0  ___U______B_______  uptodate,buddy
0x00800	      4042       15  ___________r______  reserved
0x04020	         9        0  _____l________P___  lru,private
0x04024	        14        0  __R__l________P___  referenced,lru,private
0x04028	         4        0  ___U_l________P___  uptodate,lru,private
0x0402c	         1        0  __RU_l________P___  referenced,uptodate,lru,private
0x04060	        10        0  _____lA_______P___  lru,active,private
0x04064	         7        0  __R__lA_______P___  referenced,lru,active,private
0x04068	        16        0  ___U_lA_______P___  uptodate,lru,active,private
0x20000	     24227       94  _________________n  noflags

total 131056 511

MemTotal:       508056 kB
MemFree:          7716 kB
Buffers:           220 kB
Cached:         280468 kB
SwapCached:          0 kB
Active:          31184 kB
Inactive:       271508 kB
SwapTotal:      524280 kB
SwapFree:       524232 kB
Dirty:            1284 kB
Writeback:           0 kB
AnonPages:       22044 kB
Mapped:           8652 kB
Slab:            21508 kB
SReclaimable:     4212 kB
SUnreclaim:      17296 kB
PageTables:       3036 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:    778308 kB
Committed_AS:    80544 kB
VmallocTotal: 34359738367 kB
VmallocUsed:      1740 kB
Quoted 8 lines
VmallocChunk: 34359736619 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     2048 kB
DirectMap4k:      8128 kB
DirectMap2M:    516096 kB

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#29 lore raw
Quoted 17 lines · On Wed, 11 Mar 2009 15:14:45 +0800 Wu Fengguang <[email protected]> wrote:
Quoted 16 lines · Pierre Ossman
Quoted 12 lines · On Wed, 11 Mar 2009 09:37:40 +0800 Wu Fengguang <[email protected]> wrote:

This 80MB noflags pages together with the below 80MB lru pages are very close to the missing page numbers :-) Could you run the following commands on fresh booted 2.6.27 and post the output files? Thank you!

        dd if=/dev/zero of=/tmp/s bs=1M count=1 seek=1024
        cp /tmp/s /dev/null

        ./page-flags > flags
        ./page-areas =0x20000 > areas-noflags
        ./page-areas =0x00020 > areas-lru
Quoted 9 lines
Quoted 1 line

Attached.

Thank you very much!

Quoted 1 line

I have to say, the patterns look very much like some kind of leak.

Wow it looks really interesting. The lru pages and noflags pages make perfect 1-page interleaved pattern...

Another breakthrough. I turned off everything in kernel/trace, and now the missing memory is back. Here's the relevant diff against the original .config:

@@ -3677,18 +3639,15 @@
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
-CONFIG_LATENCYTOP=y
+# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
CONFIG_HAVE_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
-CONFIG_TRACER_MAX_TRACE=y
-CONFIG_TRACING=y
# CONFIG_FTRACE is not set
-CONFIG_IRQSOFF_TRACER=y
-CONFIG_SYSPROF_TRACER=y
-CONFIG_SCHED_TRACER=y
-CONFIG_CONTEXT_SWITCH_TRACER=y
-# CONFIG_FTRACE_STARTUP_TEST is not set
+# CONFIG_IRQSOFF_TRACER is not set
+# CONFIG_SYSPROF_TRACER is not set
+# CONFIG_SCHED_TRACER is not set
+# CONFIG_CONTEXT_SWITCH_TRACER is not set

I'll enable them one at a time and see when the bug reappears, but if you have some ideas on which it could be, that would be helpful. The machine takes some time to recompile a kernel. :)

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#30 lore raw

(add cc)

Quoted 56 lines · Pierre Ossman
Quoted 17 lines · On Wed, 11 Mar 2009 15:14:45 +0800 Wu Fengguang <[email protected]> wrote:
Quoted 16 lines · Pierre Ossman
Quoted 12 lines · On Wed, 11 Mar 2009 09:37:40 +0800 Wu Fengguang <[email protected]> wrote:

This 80MB noflags pages together with the below 80MB lru pages are very close to the missing page numbers :-) Could you run the following commands on fresh booted 2.6.27 and post the output files? Thank you!

        dd if=/dev/zero of=/tmp/s bs=1M count=1 seek=1024
        cp /tmp/s /dev/null

        ./page-flags > flags
        ./page-areas =0x20000 > areas-noflags
        ./page-areas =0x00020 > areas-lru
Quoted 9 lines
Quoted 1 line

Attached.

Thank you very much!

Quoted 1 line

I have to say, the patterns look very much like some kind of leak.

Wow it looks really interesting. The lru pages and noflags pages make perfect 1-page interleaved pattern...

Another breakthrough. I turned off everything in kernel/trace, and now the missing memory is back. Here's the relevant diff against the original .config:

(quoted diff) +5 -8
@@ -3677,18 +3639,15 @@
 # CONFIG_BACKTRACE_SELF_TEST is not set
 # CONFIG_LKDTM is not set
 # CONFIG_FAULT_INJECTION is not set
-CONFIG_LATENCYTOP=y
+# CONFIG_LATENCYTOP is not set
 # CONFIG_SYSCTL_SYSCALL_CHECK is not set
 CONFIG_HAVE_FTRACE=y
 CONFIG_HAVE_DYNAMIC_FTRACE=y
-CONFIG_TRACER_MAX_TRACE=y
-CONFIG_TRACING=y
 # CONFIG_FTRACE is not set
-CONFIG_IRQSOFF_TRACER=y
-CONFIG_SYSPROF_TRACER=y
-CONFIG_SCHED_TRACER=y
-CONFIG_CONTEXT_SWITCH_TRACER=y
-# CONFIG_FTRACE_STARTUP_TEST is not set
+# CONFIG_IRQSOFF_TRACER is not set
+# CONFIG_SYSPROF_TRACER is not set
+# CONFIG_SCHED_TRACER is not set
+# CONFIG_CONTEXT_SWITCH_TRACER is not set
 
Quoted 3 lines

I'll enable them one at a time and see when the bug reappears, but if you have some ideas on which it could be, that would be helpful. The machine takes some time to recompile a kernel. :)

A quick question: are there any possibility of ftrace memory reservation?

Thanks,
Fengguang

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#31 lore raw
Quoted 3 lines · On Wed, 11 Mar 2009 15:36:19 +0800 Wu Fengguang <[email protected]> wrote:

A quick question: are there any possibility of ftrace memory reservation?

You tell me. CONFIG_FTRACE was always disabled, but CONFIG_HAVE_*FTRACE is always on. FTRACE wasn't included in 2.6.26 though, and the bisect showed only ftrace commits. So it would explain things.

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#32 lore raw
Quoted 10 lines · Pierre Ossman
Quoted 3 lines · On Wed, 11 Mar 2009 15:36:19 +0800 Wu Fengguang <[email protected]> wrote:

A quick question: are there any possibility of ftrace memory reservation?

You tell me. CONFIG_FTRACE was always disabled, but CONFIG_HAVE_*FTRACE is always on. FTRACE wasn't included in 2.6.26 though, and the bisect showed only ftrace commits. So it would explain things.

There are some __get_free_page() calls in kernel/trace/ring_buffer.c, maybe the pages are consumed by one of them?

Thanks,
Fengguang

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#33 lore raw
Quoted 4 lines · On Wed, 11 Mar 2009 16:20:38 +0800 Wu Fengguang <[email protected]> wrote:

There are some __get_free_page() calls in kernel/trace/ring_buffer.c, maybe the pages are consumed by one of them?

Perhaps. I enabled CONFIG_SYSPROF_TRACER (which pulls in ring_buffer.c). That made the "noflags" memory disappear, but the "lru" section is not there. I.e. I've lost about 80 MB instead of 170 MB.

The diff against the fully broken conf is now:

@@ -3677,17 +3640,16 @@
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
-CONFIG_LATENCYTOP=y
+# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
CONFIG_HAVE_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
-CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACING=y
# CONFIG_FTRACE is not set
-CONFIG_IRQSOFF_TRACER=y
+# CONFIG_IRQSOFF_TRACER is not set
CONFIG_SYSPROF_TRACER=y
-CONFIG_SCHED_TRACER=y
-CONFIG_CONTEXT_SWITCH_TRACER=y
+# CONFIG_SCHED_TRACER is not set
+# CONFIG_CONTEXT_SWITCH_TRACER is not set
# CONFIG_FTRACE_STARTUP_TEST is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#34 lore raw
In reply to Pierre Ossman

Hi Pierre,

Quoted 10 lines · Pierre Ossman
Quoted 3 lines · On Wed, 11 Mar 2009 15:36:19 +0800 Wu Fengguang <[email protected]> wrote:

A quick question: are there any possibility of ftrace memory reservation?

You tell me. CONFIG_FTRACE was always disabled, but CONFIG_HAVE_*FTRACE is always on. FTRACE wasn't included in 2.6.26 though, and the bisect showed only ftrace commits. So it would explain things.

I worked up a simple debugging patch. Since the missing pages are continuously spanned, several stack dumping shall be enough to catch the page consumer.

mm/page_alloc.c +7 -0
index 27b8681..c0df7fd 100644
@@ -1087,6 +1087,13 @@ again:
 			goto failed;
 	}
 
+	/* wfg - hunting the 40000 missing pages */
+	{
+		unsigned long pfn = page_to_pfn(page);
+		if (pfn > 0x1000 && (pfn & 0xfff) <= 1)
+			dump_stack();
+	}
+
 	__count_zone_vm_events(PGALLOC, zone, 1 << order);
 	zone_statistics(preferred_zone, zone);
 	local_irq_restore(flags);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#35 lore raw
Quoted 13 lines · On Wed, 11 Mar 2009 21:00:22 +0800 Wu Fengguang <[email protected]> wrote:

I worked up a simple debugging patch. Since the missing pages are continuously spanned, several stack dumping shall be enough to catch the page consumer.

mm/page_alloc.c +0 -0
index 27b8681..c0df7fd 100644
@@ -1087,6 +1087,13 @@ again:
 			goto failed;
 	}
 

mm/page_alloc.c again: · line 1099

Quoted 10 lines
mm/page_alloc.c +7 -0
+	/* wfg - hunting the 40000 missing pages */
+	{
+		unsigned long pfn = page_to_pfn(page);
+		if (pfn > 0x1000 && (pfn & 0xfff) <= 1)
+			dump_stack();
+	}
+
 	__count_zone_vm_events(PGALLOC, zone, 1 << order);
 	zone_statistics(preferred_zone, zone);
 	local_irq_restore(flags);

This got very noisy, but here's what was in the ring buffer once it had booted.

Note that this is where only the "noflags" pages have been allocated, not "lru".

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#36 lore raw
Quoted 30 lines · Pierre Ossman
Quoted 13 lines · On Wed, 11 Mar 2009 21:00:22 +0800 Wu Fengguang <[email protected]> wrote:

I worked up a simple debugging patch. Since the missing pages are continuously spanned, several stack dumping shall be enough to catch the page consumer.

mm/page_alloc.c +0 -0
index 27b8681..c0df7fd 100644
@@ -1087,6 +1087,13 @@ again:
 			goto failed;
 	}
 

mm/page_alloc.c again: · line 1099

Quoted 10 lines
mm/page_alloc.c +7 -0
+	/* wfg - hunting the 40000 missing pages */
+	{
+		unsigned long pfn = page_to_pfn(page);
+		if (pfn > 0x1000 && (pfn & 0xfff) <= 1)
+			dump_stack();
+	}
+
 	__count_zone_vm_events(PGALLOC, zone, 1 << order);
 	zone_statistics(preferred_zone, zone);
 	local_irq_restore(flags);

This got very noisy, but here's what was in the ring buffer once it had booted.

Quoted 2 lines

Note that this is where only the "noflags" pages have been allocated, not "lru".

BTW, which kernel are you testing? 2.6.27, ftrace had its own special buffering system. It played tricks with the page structs of the pages in the buffer. It used the lru parts of the pages to link list itself. I just booted on a straight 2.6.27 with tracing configured.

# cat /debug/tracing/trace_entries 
65586

This is the old method to see the amount of data used. There are a total of 65,586 entries all of 88 bytes each: 5,771,568 And since we also have a "snapshot" buffer for max latencies, the total is: 11,543,136. That is quite a lot of memory for one CPU :-/

Starting with 2.6.28, we now have the unified ring buffer. It removes all of the page struct hackery in the original code.

In 2.6.28, the trace_entries is a misnomer. The conversion to the ring buffer brought had the change from representing the number of entries (entries in the ring buffer are now variable length) and the count is the number of bytes each CPU buffer takes up (*2 because of the "snapshot" buffer).

# cat /debug/tracing/trace_entries 
1441792

Now we have 1,441,792 or about 3 megs as the default.

Today, we now have it as:

# cat /debug/tracing/buffer_size_kb 
1410

Still the 3 megs. But going from 10Megs a CPU, to 3Megs is a big difference. Do you see the same amout of lost memory with the later kernels?

I'll have to make the option to expand the ring buffer when a tracer is registered. That will be the default option.

-- Steve

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#37 lore raw
Quoted 6 lines · On Wed, 11 Mar 2009 11:47:16 -0400 (EDT) Steven Rostedt <[email protected]>…

BTW, which kernel are you testing? 2.6.27, ftrace had its own special buffering system. It played tricks with the page structs of the pages in the buffer. It used the lru parts of the pages to link list itself. I just booted on a straight 2.6.27 with tracing configured.

I've been primarily testing 2.6.27, yes. I think I tested 2.6.29-rc7 at the beginning of this, but my memory is a bit fuzzy so I better retest.

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#38 lore raw
Quoted 4 lines · On Wed, 11 Mar 2009 17:46:38 +0100 Pierre Ossman <[email protected]> wrote:
Quoted 1 line · On Wed, 11 Mar 2009 11:47:16 -0400 (EDT) Steven Rostedt <[email protected]>…
Quoted 9 lines
Quoted 5 lines

BTW, which kernel are you testing? 2.6.27, ftrace had its own special buffering system. It played tricks with the page structs of the pages in the buffer. It used the lru parts of the pages to link list itself. I just booted on a straight 2.6.27 with tracing configured.

I've been primarily testing 2.6.27, yes. I think I tested 2.6.29-rc7 at the beginning of this, but my memory is a bit fuzzy so I better retest.

Annoying... 2.6.28 and newer refuses to boot. Has someone broken the virtio_blk interface?

I'll reconfigure it to use piix tomorrow and see if I can get it running.

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#39 lore raw
Quoted 4 lines · On Wed, 11 Mar 2009 22:43:53 +0100 Pierre Ossman <[email protected]> wrote:

I'll reconfigure it to use piix tomorrow and see if I can get it running.

No dice. In both cases (virtio_blk and piix), it sees the disk and reads the partitions, but then fails to find any volume groups. Does this ring any bells?

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#40 lore raw
In reply to Pierre Ossman
Quoted 16 lines · Pierre Ossman
Quoted 13 lines · On Wed, 11 Mar 2009 21:00:22 +0800 Wu Fengguang <[email protected]> wrote:

I worked up a simple debugging patch. Since the missing pages are continuously spanned, several stack dumping shall be enough to catch the page consumer.

mm/page_alloc.c +0 -0
index 27b8681..c0df7fd 100644
@@ -1087,6 +1087,13 @@ again:
 			goto failed;
 	}
 
Quoted 13 lines

mm/page_alloc.c again: · line 1099

Quoted 10 lines
mm/page_alloc.c +7 -0
+	/* wfg - hunting the 40000 missing pages */
+	{
+		unsigned long pfn = page_to_pfn(page);
+		if (pfn > 0x1000 && (pfn & 0xfff) <= 1)
+			dump_stack();
+	}
+
 	__count_zone_vm_events(PGALLOC, zone, 1 << order);
 	zone_statistics(preferred_zone, zone);
 	local_irq_restore(flags);

This got very noisy, but here's what was in the ring buffer once it had booted.

It's about 20 stack dumps, hehe. Could you please paste some of them? Thank you!

Quoted 2 lines

Note that this is where only the "noflags" pages have been allocated, not "lru".

The lru pages have even numbered pfn, the noflags pages have odd numbered pfn. So if it's 1-page allocations, the ((pfn & 0xfff) <= 1) will match both lru and noflags pages.

Thanks,
Fengguang

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#41 lore raw
Quoted 31 lines · On Thu, 12 Mar 2009 09:08:16 +0800 Wu Fengguang <[email protected]> wrote:
Quoted 16 lines · Pierre Ossman
Quoted 13 lines · On Wed, 11 Mar 2009 21:00:22 +0800 Wu Fengguang <[email protected]> wrote:

I worked up a simple debugging patch. Since the missing pages are continuously spanned, several stack dumping shall be enough to catch the page consumer.

mm/page_alloc.c +0 -0
index 27b8681..c0df7fd 100644
@@ -1087,6 +1087,13 @@ again:
 			goto failed;
 	}
 
Quoted 13 lines

mm/page_alloc.c again: · line 1099

Quoted 10 lines
mm/page_alloc.c +7 -0
+	/* wfg - hunting the 40000 missing pages */
+	{
+		unsigned long pfn = page_to_pfn(page);
+		if (pfn > 0x1000 && (pfn & 0xfff) <= 1)
+			dump_stack();
+	}
+
 	__count_zone_vm_events(PGALLOC, zone, 1 << order);
 	zone_statistics(preferred_zone, zone);
 	local_irq_restore(flags);

This got very noisy, but here's what was in the ring buffer once it had booted.

Quoted 3 lines

It's about 20 stack dumps, hehe. Could you please paste some of them? Thank you!

Ooops, I meant to attach the dmesg output. Let's try again. :)

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#42 lore raw
Quoted 34 lines · Pierre Ossman
Quoted 31 lines · On Thu, 12 Mar 2009 09:08:16 +0800 Wu Fengguang <[email protected]> wrote:
Quoted 29 lines · Pierre Ossman
Quoted 13 lines · On Wed, 11 Mar 2009 21:00:22 +0800 Wu Fengguang <[email protected]> wrote:

I worked up a simple debugging patch. Since the missing pages are continuously spanned, several stack dumping shall be enough to catch the page consumer.

mm/page_alloc.c +0 -0
index 27b8681..c0df7fd 100644
@@ -1087,6 +1087,13 @@ again:
 			goto failed;
 	}
 

mm/page_alloc.c again: · line 1099

Quoted 10 lines
mm/page_alloc.c +7 -0
+	/* wfg - hunting the 40000 missing pages */
+	{
+		unsigned long pfn = page_to_pfn(page);
+		if (pfn > 0x1000 && (pfn & 0xfff) <= 1)
+			dump_stack();
+	}
+
 	__count_zone_vm_events(PGALLOC, zone, 1 << order);
 	zone_statistics(preferred_zone, zone);
 	local_irq_restore(flags);

This got very noisy, but here's what was in the ring buffer once it had booted.

Quoted 5 lines
Quoted 3 lines

It's about 20 stack dumps, hehe. Could you please paste some of them? Thank you!

Ooops, I meant to attach the dmesg output. Let's try again. :)

Ooops, there're no ftrace in the dmesg. They are pretty normal page faults. I overlooked the possibility of repeated alloc/free cycles on the same pfn...

Anyway please go on with Steven's ftrace patchset :-)

Thanks,
Fengguang

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#43 lore raw
In reply to Wu Fengguang
Quoted 27 lines · Wu Fengguang
Quoted 27 lines
Quoted 13 lines
Quoted 13 lines
Quoted 12 lines

This 80MB noflags pages together with the below 80MB lru pages are very close to the missing page numbers :-) Could you run the following commands on fresh booted 2.6.27 and post the output files? Thank you!

        dd if=/dev/zero of=/tmp/s bs=1M count=1 seek=1024
        cp /tmp/s /dev/null

        ./page-flags > flags
        ./page-areas =0x20000 > areas-noflags
        ./page-areas =0x00020 > areas-lru
Quoted 9 lines
Quoted 1 line

Attached.

Thank you very much!

Quoted 1 line

I have to say, the patterns look very much like some kind of leak.

Wow it looks really interesting. The lru pages and noflags pages make perfect 1-page interleaved pattern...

Another breakthrough. I turned off everything in kernel/trace, and now the missing memory is back. Here's the relevant diff against the original .config:

[..]

Quoted 6 lines
Quoted 4 lines

I'll enable them one at a time and see when the bug reappears, but if you have some ideas on which it could be, that would be helpful. The machine takes some time to recompile a kernel. :)

A quick question: are there any possibility of ftrace memory reservation?

The ring buffer is allocated at start up (although I'm thinking of making it allocated when it is first used), and the allocations are done percpu.

It allocates around 3 megs per cpu. How many CPUs were on this box?

-- Steve

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#44 lore raw
Quoted 6 lines · On Wed, 11 Mar 2009 10:25:10 -0400 (EDT) Steven Rostedt <[email protected]>…

The ring buffer is allocated at start up (although I'm thinking of making it allocated when it is first used), and the allocations are done percpu.

It allocates around 3 megs per cpu. How many CPUs were on this box?

One. :)

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#45 lore raw
In reply to Steven Rostedt
Quoted 6 lines · On Wed, 11 Mar 2009 10:25:10 -0400 (EDT) Steven Rostedt <[email protected]>…

The ring buffer is allocated at start up (although I'm thinking of making it allocated when it is first used), and the allocations are done percpu.

It allocates around 3 megs per cpu. How many CPUs were on this box?

Is this per actual CPU though? Or per CONFIG_NR_CPUS? 3 MB times 64 equals roughly the lost memory. But then again, you said it was 10 MB per CPU for 2.6.27...

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#46 lore raw
Quoted 7 lines · Pierre Ossman
Quoted 4 lines · On Wed, 11 Mar 2009 10:25:10 -0400 (EDT) Steven Rostedt <[email protected]>…

The ring buffer is allocated at start up (although I'm thinking of making it allocated when it is first used), and the allocations are done percpu.

Quoted 6 lines
Quoted 2 lines

It allocates around 3 megs per cpu. How many CPUs were on this box?

Is this per actual CPU though? Or per CONFIG_NR_CPUS? 3 MB times 64 equals roughly the lost memory. But then again, you said it was 10 MB per CPU for 2.6.27...

It uses the possible_cpu mask. How many possible CPUs are on your box? I've thought about making this handle hot plug CPUs, but that will require a little more overhead for everyone, whether or not you hot plug a cpu.

-- Steve

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#47 lore raw
Quoted 4 lines · On Wed, 11 Mar 2009 13:28:31 -0400 (EDT) Steven Rostedt <[email protected]>…
Quoted 1 line · Pierre Ossman
Quoted 9 lines
Quoted 3 lines

Is this per actual CPU though? Or per CONFIG_NR_CPUS? 3 MB times 64 equals roughly the lost memory. But then again, you said it was 10 MB per CPU for 2.6.27...

It uses the possible_cpu mask. How many possible CPUs are on your box? I've thought about making this handle hot plug CPUs, but that will require a little more overhead for everyone, whether or not you hot plug a cpu.

CONFIG_NR_CPUS is 64 for these compiles.

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#48 lore raw
Quoted 11 lines · Pierre Ossman
Quoted 8 lines · On Wed, 11 Mar 2009 13:28:31 -0400 (EDT) Steven Rostedt <[email protected]>…
Quoted 4 lines · Pierre Ossman

Is this per actual CPU though? Or per CONFIG_NR_CPUS? 3 MB times 64 equals roughly the lost memory. But then again, you said it was 10 MB per CPU for 2.6.27...

Quoted 7 lines
Quoted 5 lines

It uses the possible_cpu mask. How many possible CPUs are on your box? I've thought about making this handle hot plug CPUs, but that will require a little more overhead for everyone, whether or not you hot plug a cpu.

CONFIG_NR_CPUS is 64 for these compiles.

Hmm, I assumed (but could be wrong) that on boot up, the system checked how many CPUs were physically possible, and updated the possible CPU mask accordingly (default being NR_CPUS).

If this is not the case, then I'll have to implement hot plug allocation. :-/

Thanks,

-- Steve

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#49 lore raw
Quoted 8 lines · On Wed, 11 Mar 2009 14:48:02 -0400 (EDT) Steven Rostedt <[email protected]>…

Hmm, I assumed (but could be wrong) that on boot up, the system checked how many CPUs were physically possible, and updated the possible CPU mask accordingly (default being NR_CPUS).

If this is not the case, then I'll have to implement hot plug allocation. :-/

I have no idea, but every system doesn't suffer from this problem so there is something more to this. Modern fedora kernels have NR_CPUS set to 512, and it's not like I'm missing 1.5 GB here. :)

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#50 lore raw
Quoted 8 lines · Pierre Ossman
Quoted 5 lines · On Wed, 11 Mar 2009 14:48:02 -0400 (EDT) Steven Rostedt <[email protected]>…

Hmm, I assumed (but could be wrong) that on boot up, the system checked how many CPUs were physically possible, and updated the possible CPU mask accordingly (default being NR_CPUS).

Quoted 8 lines
Quoted 3 lines

If this is not the case, then I'll have to implement hot plug allocation. :-/

I have no idea, but every system doesn't suffer from this problem so there is something more to this. Modern fedora kernels have NR_CPUS set to 512, and it's not like I'm missing 1.5 GB here. :)

I'm thinking it is a system dependent feature. I'm working on implementing the ring buffers to only allocate for online CPUS. I just realized that there's a check of a ring buffer cpu mask to see if it is OK to write to that CPU buffer. This works out perfectly, to keep non allocated buffers from being written to.

Thanks,

-- Steve

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#51 lore raw
Quoted 7 lines · Pierre Ossman
Quoted 5 lines
Quoted 1 line · On Wed, 11 Mar 2009 14:48:02 -0400 (EDT) Steven Rostedt <[email protected]>…
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines

Hmm, I assumed (but could be wrong) that on boot up, the system checked how many CPUs were physically possible, and updated the possible CPU mask accordingly (default being NR_CPUS).

If this is not the case, then I'll have to implement hot plug allocation. :-/

Pierre, Could you please operate following command and post result?

# cat /sys/devices/system/cpu/possible

this is outputting the possible cpus of your system.

Quoted 13 lines
Quoted 4 lines

I have no idea, but every system doesn't suffer from this problem so there is something more to this. Modern fedora kernels have NR_CPUS set to 512, and it's not like I'm missing 1.5 GB here. :)

I'm thinking it is a system dependent feature. I'm working on implementing the ring buffers to only allocate for online CPUS. I just realized that there's a check of a ring buffer cpu mask to see if it is OK to write to that CPU buffer. This works out perfectly, to keep non allocated buffers from being written to.

Thanks,

Quoted 7 lines

-- Steve

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#52 lore raw
Quoted 5 lines · On Thu, 12 Mar 2009 11:46:31 +0900 (JST) KOSAKI Motohiro…

Pierre, Could you please operate following command and post result?

# cat /sys/devices/system/cpu/possible

[root@builder ~]# cat /sys/devices/system/cpu/possible 0-15

16 times 11 MB also is the amount of lost memory, so this seems reasonable.

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#53 lore raw
In reply to Wu Fengguang

Ok, I think I've found some, but not all of the missing memory.

I had to remove PG_swapbacked and PG_private2 as 2.6.26/2.6.27 didn't have those bits.

After that, a comparison shows that this row is in 2.6.27, but not 2.6.26:

0x00020 20576 80 _____l____________ lru

Unfortunately there are about 170 MB of missing memory, not 80. So we probably need to dig deeper. But does the above say anything to you?

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.
#54 lore raw
In reply to Pierre Ossman

Hi

Quoted 10 lines
Quoted 9 lines

Here is the initial patch and tool for finding the missing pages.

In the following example, the pages with no flags set is kind of too many (1816MB), but hopefully your missing pages will have PG_reserved or other flags set ;-)

# ./page-types
L:locked E:error R:referenced U:uptodate D:dirty L:lru A:active S:slab W:writeback x:reclaim B:buddy r:reserved c:swapcache b:swapbacked
Quoted 6 lines

Thanks. I'll have a look in a bit. Right now I'm very close to a complete bisect. It is just ftrace commits left though, so I'm somewhat sceptical that it is correct. ftrace isn't even turned on in the kernels I've been testing.

The remaining commits are ec1bb60bb..6712e299.

Can you try to turn off CONFIG_FTRACE* build option?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#55 lore raw
Quoted 3 lines · On Wed, 11 Mar 2009 09:19:32 +0900 (JST) KOSAKI Motohiro…

Can you try to turn off CONFIG_FTRACE* build option?

That's just it, it is off.

Rgds

Signature · 6 lines
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.