linux-kernel - Re: [PATCH] mm: cma: allocate pages from CMA if NR_FREE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121121132540.GA2084@barrios>
Date:	Wed, 21 Nov 2012 22:25:41 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Michal Nazarewicz <mina86@...a86.com>
Cc:	Marek Szyprowski <m.szyprowski@...sung.com>, linux-mm@...ck.org,
	linaro-mm-sig@...ts.linaro.org, linux-kernel@...r.kernel.org,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mel@....ul.ie>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [PATCH] mm: cma: allocate pages from CMA if NR_FREE_PAGES
 approaches low water mark

On Wed, Nov 21, 2012 at 02:07:04PM +0100, Michal Nazarewicz wrote:
> On Wed, Nov 21 2012, Minchan Kim wrote:
> > So your concern is that too many free pages in MIGRATE_CMA when OOM happens
> > is odd? It's natural with considering CMA design which kernel never fallback
> > non-movable page allocation to CMA area. I guess it's not a your concern.
> >
> > Let's think below extreme cases.
> >
> > = Before =
> >
> > * 1000M DRAM system.
> > * 400M kernel used pages.
> > * 300M movable used pages.
> > * 300M cma freed pages.
> >
> > 1. kernel want to request 400M non-movable memory, additionally.
> > 2. VM start to reclaim 300M movable pages.
> > 3. But it's not enough to meet 400M request.
> > 4. go to OOM. (It's natural)
> >
> > = After(with your patch) =
> >
> > * 1000M DRAM system.
> > * 400M kernel used pages.
> > * 300M movable *freed* pages.
> > * 300M cma used pages(by your patch, I simplified your concept)
> >
> > 1. kernel want to request 400M non-movable memory.
> > 2. 300M movable freed pages isn't enough to meet 400M request.
> > 3. Also, there is no point to reclaim CMA pages for non-movable allocation.
> > 4. go to OOM. (It's natural)
> >
> > There is no difference between before and after in allocation POV.
> > Let's think another example.
> >
> > = Before =
> >
> > * 1000M DRAM system.
> > * 400M kernel used pages.
> > * 300M movable used pages.
> > * 300M cma freed pages.
> >
> > 1. kernel want to request 300M non-movable memory.
> > 2. VM start to reclaim 300M movable pages.
> > 3. It's enough to meet 300M request.
> > 4. happy end
> >
> > = After(with your patch) =
> >
> > * 1000M DRAM system.
> > * 400M kernel used pages.
> > * 300M movable *freed* pages.
> > * 300M cma used pages(by your patch, I simplified your concept)
> >
> > 1. kernel want to request 300M non-movable memory.
> > 2. 300M movable freed pages is enough to meet 300M request.
> > 3. happy end.
> >
> > There is no difference in allocation POV, too.
> 
> The difference thou is that before 30% of memory is wasted (ie. free),
> whereas after all memory is used.  The main point of CMA is to make the
> memory useful if devices are not using it.  Having it not allocated is
> defeating that purpose.

I think it's not a waste because if reclaimed movable pages is working set,
they are soon reloaded to migrate_cma in this time.

> 
> -- 
> Best regards,                                         _     _
> .o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
> ..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
> ooo +----<email/xmpp: mpn@...gle.com>--------------ooO--(_)--Ooo--





-- 
Kind Regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/