Hi,
We have a system (2.6.27 based) which seems to be increasing its memory
consumption by several MB an hour. Summing up Pss for all maps in all
processes doesn't seem to explain it, so I'm looking at the kernel.
I've backported the kmemleak functionality. It's self-test module shows
leaks so I know it's working, but it doesn't report any leaks that would
correspond to the memory increase.
I'm currently trying to figure out which of the entries in /proc/meminfo
are actually orthogonal to each other. Ideally I'd like to be able to
add up the suitable entries and have it work out to the total memory on
the system, so that I can then narrow down exactly where the memory is
going. Is this feasable?
I'll keep reading the code but if anyone happens to know this already
I'd appreciate some assistance.
Thanks,
Chris
On 01/26/2010 01:03 PM, Chris Friesen wrote:
> I'm currently trying to figure out which of the entries in /proc/meminfo
> are actually orthogonal to each other. Ideally I'd like to be able to
> add up the suitable entries and have it work out to the total memory on
> the system, so that I can then narrow down exactly where the memory is
> going. Is this feasable?
I've tried adding up
MemFree+Buffers+Cached+AnonPages+Mapped+Slab+PageTables+VmallocUsed
(hugepages are disabled and there is no swap)
Shortly after boot this gets me within about 3MB of MemTotal. However,
after 1070 minutes there is a 64MB difference between MemTotal and the
above sum.
Here's /proc/meminfo after 1070 minutes:
MemTotal: 4042848 kB
MemFree: 406112 kB
Buffers: 12072 kB
Cached: 3068368 kB
SwapCached: 0 kB
Active: 671200 kB
Inactive: 2711952 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 44 kB
Writeback: 0 kB
AnonPages: 235864 kB
Mapped: 30752 kB
Slab: 200156 kB
SReclaimable: 142828 kB
SUnreclaim: 57328 kB
PageTables: 4320 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 2021424 kB
Committed_AS: 2593116 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 21496 kB
VmallocChunk: 34359716779 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 3008 kB
DirectMap2M: 4190208 kB
Any ideas how to track down the missing memory?
Chris
On 01/26/2010 02:47 PM, Chris Friesen wrote:
> I've tried adding up
> MemFree+Buffers+Cached+AnonPages+Mapped+Slab+PageTables+VmallocUsed
>
> (hugepages are disabled and there is no swap)
>
> Shortly after boot this gets me within about 3MB of MemTotal. However,
> after 1070 minutes there is a 64MB difference between MemTotal and the
> above sum.
Oddly enough, over the same period it appears that
MemFree + Active + Inactive + Slab + PageTables
is basically (+/- half a meg) constant and equal to "MemTotal - 48.5MB".
It would seem that active/inactive track memory that isn't visible in
Buffers+Cached+AnonPages+Mapped. Anyone have any suggestions what it
might be?
Thanks,
Chris
On Tue, 2010-01-26 at 14:47 -0600, Chris Friesen wrote:
> On 01/26/2010 01:03 PM, Chris Friesen wrote:
>
> > I'm currently trying to figure out which of the entries in /proc/meminfo
> > are actually orthogonal to each other. Ideally I'd like to be able to
> > add up the suitable entries and have it work out to the total memory on
> > the system, so that I can then narrow down exactly where the memory is
> > going. Is this feasable?
>
> I've tried adding up
> MemFree+Buffers+Cached+AnonPages+Mapped+Slab+PageTables+VmallocUsed
VmallocUsed referws to Vmalloc address space consumption. However,
Vmalloc address space is not used exclusively to map system RAM into
virtual address space. It is also used to map PCI MMIO windows to the
register sets or memory chips on PCI cards into the vritual address
space.
Regards,
Andy
> (hugepages are disabled and there is no swap)
>
> Shortly after boot this gets me within about 3MB of MemTotal. However,
> after 1070 minutes there is a 64MB difference between MemTotal and the
> above sum.
>
> Here's /proc/meminfo after 1070 minutes:
>
> MemTotal: 4042848 kB
> MemFree: 406112 kB
> Buffers: 12072 kB
> Cached: 3068368 kB
> SwapCached: 0 kB
> Active: 671200 kB
> Inactive: 2711952 kB
> SwapTotal: 0 kB
> SwapFree: 0 kB
> Dirty: 44 kB
> Writeback: 0 kB
> AnonPages: 235864 kB
> Mapped: 30752 kB
> Slab: 200156 kB
> SReclaimable: 142828 kB
> SUnreclaim: 57328 kB
> PageTables: 4320 kB
> NFS_Unstable: 0 kB
> Bounce: 0 kB
> WritebackTmp: 0 kB
> CommitLimit: 2021424 kB
> Committed_AS: 2593116 kB
> VmallocTotal: 34359738367 kB
> VmallocUsed: 21496 kB
> VmallocChunk: 34359716779 kB
> HugePages_Total: 0
> HugePages_Free: 0
> HugePages_Rsvd: 0
> HugePages_Surp: 0
> Hugepagesize: 2048 kB
> DirectMap4k: 3008 kB
> DirectMap2M: 4190208 kB
>
> Any ideas how to track down the missing memory?
>
> Chris
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, Jan 26, 2010 at 02:47:26PM -0600, Chris Friesen wrote:
> I've tried adding up
> MemFree+Buffers+Cached+AnonPages+Mapped+Slab+PageTables+VmallocUsed
>
> (hugepages are disabled and there is no swap)
>
> Shortly after boot this gets me within about 3MB of MemTotal. However,
> after 1070 minutes there is a 64MB difference between MemTotal and the
> above sum.
I believe that pages allocated directly with get_free_pages won't show
up in your sum. So, just look for someone doing a lot of that :-)
Jeff
Hi Andy,
I am seeing similar kind of issue, where SUnreclaim increases. How did
you resolve your issue.
Thanks
Jayasri
Andy Walls-2 wrote:
>
> On Tue, 2010-01-26 at 14:47 -0600, Chris Friesen wrote:
>> On 01/26/2010 01:03 PM, Chris Friesen wrote:
>>
>> > I'm currently trying to figure out which of the entries in
>> /proc/meminfo
>> > are actually orthogonal to each other. Ideally I'd like to be able to
>> > add up the suitable entries and have it work out to the total memory on
>> > the system, so that I can then narrow down exactly where the memory is
>> > going. Is this feasable?
>>
>> I've tried adding up
>> MemFree+Buffers+Cached+AnonPages+Mapped+Slab+PageTables+VmallocUsed
>
> VmallocUsed referws to Vmalloc address space consumption. However,
> Vmalloc address space is not used exclusively to map system RAM into
> virtual address space. It is also used to map PCI MMIO windows to the
> register sets or memory chips on PCI cards into the vritual address
> space.
>
> Regards,
> Andy
>
>
>> (hugepages are disabled and there is no swap)
>>
>> Shortly after boot this gets me within about 3MB of MemTotal. However,
>> after 1070 minutes there is a 64MB difference between MemTotal and the
>> above sum.
>>
>> Here's /proc/meminfo after 1070 minutes:
>>
>> MemTotal: 4042848 kB
>> MemFree: 406112 kB
>> Buffers: 12072 kB
>> Cached: 3068368 kB
>> SwapCached: 0 kB
>> Active: 671200 kB
>> Inactive: 2711952 kB
>> SwapTotal: 0 kB
>> SwapFree: 0 kB
>> Dirty: 44 kB
>> Writeback: 0 kB
>> AnonPages: 235864 kB
>> Mapped: 30752 kB
>> Slab: 200156 kB
>> SReclaimable: 142828 kB
>> SUnreclaim: 57328 kB
>> PageTables: 4320 kB
>> NFS_Unstable: 0 kB
>> Bounce: 0 kB
>> WritebackTmp: 0 kB
>> CommitLimit: 2021424 kB
>> Committed_AS: 2593116 kB
>> VmallocTotal: 34359738367 kB
>> VmallocUsed: 21496 kB
>> VmallocChunk: 34359716779 kB
>> HugePages_Total: 0
>> HugePages_Free: 0
>> HugePages_Rsvd: 0
>> HugePages_Surp: 0
>> Hugepagesize: 2048 kB
>> DirectMap4k: 3008 kB
>> DirectMap2M: 4190208 kB
>>
>> Any ideas how to track down the missing memory?
>>
>> Chris
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>> in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
View this message in context: http://old.nabble.com/which-fields-in--proc-meminfo-are-orthogonal--tp27328047p29337843.html
Sent from the linux-kernel mailing list archive at Nabble.com.