linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Lisa Du <cldu@marvell.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: NR_FREE_CMA_PAGES larger than total CMA size
Date: Mon, 7 Jul 2014 13:53:49 +0900	[thread overview]
Message-ID: <20140707045349.GB29236@js1304-P5Q-DELUXE> (raw)
In-Reply-To: <89813612683626448B837EE5A0B6A7CB455AEB75CF@SC-VEXCH4.marvell.com>

On Sat, Jul 05, 2014 at 01:13:17AM -0700, Lisa Du wrote:
> Dear Sir
> Recently I met one issue that after system run for a long time, free cma pages recorded
> in vm_stat[NR_FREE_CMA_PAGES] are larger than total CMA size declared.
> For example, I declared 64MB CMA size, but found free cma was 70MB.
> 
> I added some trace to track how it happen, and found the reason maybe like below:
> 1) alloc_contig_range() want to allocate a range [start, end], for example [0x1e040, 0x1e050];
> 
> 2) start_isolate_page_range() will isolate the range [pfn_max_align_down(start),
>   pfn_max_align_up(end)]; for this example it's [0x1e000, 0x1e400] (MAX_ORDER is 11);
> 
> 3) drain_all_pages() would be called as follows, if there's some pages belong to the range
>   [0x1e000, 0x1e400] was freed from the pcp_list, also if the page was MIGRATE_CMA,
>   then vm_stat[NR_FREE_CMA_PAGES] would increase and also NR_FREE_PAGES;
> 
> 4) if the freed pages in #3 was not the range of [start, end], then at last undo_isolate_page_range()
>   will be called, and the pages would be calculated again as free pages in unset_migratetype_isolate(),
>   and __mod_zone_freepage_state() will increased again for these pages for both NR_FREE_CMA_PAGES
>   and NR_FREE_PAGES. 
>   The function calling flow as below, the free pages in move_freepages() was calculated again.
>   undo_isolate_page_range()
> 	--> unset_migratetype_isolate()
> 		--> move_freepages_block()
> 			--> move_freepages()
> 	--> __mod_zone_freepage_state()
> 
> Shall we add some check in move_freepages() if the page was already in CMA free list, 
> then exclude it from the pages_moved?
> 
> I found this issue in kernel v3.4, but seems there's no fix in latest kernel code base.
> Not sure if anyone else has met such issue? Anyone would help to comment? Thanks a lot!

Hello,

Maybe this bug is relevant for my recent patchset.
I don't have much time to investigate your problem, so
if you have interest on my patchset, please look at it on below link

https://lkml.org/lkml/2014/7/4/79

If they work for you, please let me know. :)

Thanks.

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

  reply	other threads:[~2014-07-07  4:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-05  8:13 Lisa Du
2014-07-07  4:53 ` Joonsoo Kim [this message]
2014-07-10  0:55   ` Lisa Du

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140707045349.GB29236@js1304-P5Q-DELUXE \
    --to=iamjoonsoo.kim@lge.com \
    --cc=cldu@marvell.com \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox