On Jul 22, 2014, at 11:56 PM, Richard W.M. Jones wrote: > On Tue, Jul 22, 2014 at 11:42:32PM +0900, Jungseok Lee wrote: >> On Jul 21, 2014, at 9:45 PM, Richard W.M. Jones wrote: >> >> [ ... ] >> >>> I have spent a bit of time inserting printks around memory allocations >>> in arch/arm/kvm/mmu.c (since that file seems to be responsible for >>> guest page tables and guest memory allocation) but I haven't come up >>> with anything conclusive. >> >> Hi, Richard >> >> Have you figure out this issue? > > No. > >> IMHO, it is needed to dive into three functions: mmu_topup_memory_cache, >> mmu_free_memory_cache and mum_memory_cache_alloc. They manage both the >> number of allocated (cached) pages and the number of usable pages with >> a single parameter, nobjs. However, they can have different values and >> mmu_free_memory_cache only refers to the number of usable pages, not the >> total number of allocated pages. >> >> When VM launches, mmu_topup_memory_cache is called with min=2 and max=40. >> nobjs is set to 40 at this time frame. As mmu_memory_cache_alloc is called, >> nobjs is decreased. Let's try to destroy VM now. mmu_free_memory_cache tries >> to free smaller pages instead of 40 pages. It reaches to memory leak. > > Yes I tried adding printk's into these functions. There is a possible > leak. Unfortunately I'm not clear on how / if `put_page' frees a > page. I kind of assume it's using some kind of reference counting, > but I'm not sure. If `put_page' is releasing the page, then maybe > there isn't a leak in these functions. I will take a close look in reference counting perspective. If I get a clue, I will let you know. - Jungseok Lee _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
