Re: Memory leaks on atom-based boards?

From: Vlastimil Babka <vbabka@suse.cz>
To: AL13N <alien@rmail.be>, linux-kernel@vger.kernel.org
Subject: Re: Memory leaks on atom-based boards?
Date: Sun, 09 Nov 2014 23:07:23 +0100	[thread overview]
Message-ID: <545FE59B.3020702@suse.cz> (raw)
In-Reply-To: <27d4dc6a448169861446f8c1b3c3cadd.squirrel@mail.rmail.be>

On 11/09/2014 05:38 PM, AL13N wrote:
>> On 10/27/2014 07:44 PM, AL13N wrote:
>>
>> Hi, this does look like a kernel memory leak. There was recently a known
>> one fixed by patch from https://lkml.org/lkml/2014/10/15/447 which made
>> it to 3.18-rc3 and should be backported to stable kernels 3.8+ soon.
>> You would recognize if this is the fix for you by checking the
>> thp_zero_page_alloc value in /proc/vmstat. Value X > 1 basically means
>> that X*2 MB memory is leaked.
>> You say in the serverfault post that 3.17.2 helped, but the fix is not
>> in 3.17.2... but it could be just that the circumstances changed and THP
>> zero pages are no longer freed and realocated.
>> So if you want to be sure, I would suggest trying again a version where
>> the problem appeared on your system, and checking the
>> thp_zero_page_alloc. Perhaps you'll see a >1 value even on 3.17.2, which
>> means some leak did occur there as well, but maybe not so severe.
> 
> 
> i was gonna tell you guys, but i was waiting until i was sure, but indeed
> 3.17.2 fixed, it, where i had OOM after 3, maybe 4 days (for at least 2
> months), now i'm up more than 4 days and the MemAvailable is still high
> enough... at about 3.5GB whereas otherwise it would dwindle until 0. (at
> about 1GB/day)
> 
> Well, it results to 0 on 3.17.2 ... so... i guess not? i'll keep this
> value under observation...

Hm, 0 sounds like nobody was allocating transparent huge pages at all. What
about the other thp_* stats?

>>>  - How can i find out what is allocating all this memory?
>>
>> There's no simple way, unfortunately. Checking the kpageflags /proc file
>> might help. IIRC there used to be a patch in -mm tree to store who
>> allocated what page, but it might be bitrotten.
> 
> 
> i checked what was in kpageflags (or kpagecount) but it's all some kind of
> binary stuff...
> 
> do i need some tool to interprete these values?

There's tools/vm/page-types.c in kernel sources which can read kpageflags, but
not the kpagecount...

Vlastimil