page_owner didn't help, at least not directly. As the pages "leak",
they stop showing up in page_owner, which means they're in the
allocator. Check out buddyinfo/meminfo:
> dave@nimitz:~/ltc/linux.git$ cat /proc/buddyinfo /proc/meminfo
> Node 0, zone DMA 0 0 0 1 2 1 1 0 1 1 3
> Node 0, zone DMA32 25450 13645 11665 2994 1242 665 234 50 12 1 1
> Node 0, zone Normal 6494 28630 16790 5872 3524 1666 844 238 146 60 398
> MemTotal: 7825604 kB
> MemFree: 1285260 kB
...
Just the 398 order-10 zone Normal pages account for ~1.6GB of free
memory, yet the MemFree is ~1.3GB, and that's a *SINGLE* bucket in the
buddy allocator. Adding them all up, it's fairly close to the amount of
memory that I'm missing at the moment.
Rather than being a real leak, it looks like this might just be an
accounting problem:
$ cat /proc/zoneinfo | egrep 'free_pages|Node'
Node 0, zone DMA
nr_free_pages 3976
Node 0, zone DMA32
nr_free_pages 177041
Node 0, zone Normal
nr_free_pages 16148
That 16148 pages for ZONE_NORMAL is obviously bogus compared to what
buddyinfo is saying.
Commit d1ce749a0d did mess with NR_FREE_PAGES accounting quite a bit.
Guess I'll try a revert and see where I end up.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>