[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xa1tzjiddyrr.fsf@mina86.com>
Date: Mon, 19 May 2014 15:28:24 -1000
From: Michal Nazarewicz <mina86@...a86.com>
To: Gioh Kim <gioh.kim@....com>, Joonsoo Kim <iamjoonsoo.kim@....com>
Cc: Minchan Kim <minchan.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>,
Laura Abbott <lauraa@...eaurora.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
Heesub Shin <heesub.shin@...sung.com>,
Mel Gorman <mgorman@...e.de>,
Johannes Weiner <hannes@...xchg.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
이건호 <gunho.lee@....com>, gurugio@...il.com
Subject: Re: [RFC][PATCH] CMA: drivers/base/Kconfig: restrict CMA size to non-zero value
On Mon, May 19 2014, Gioh Kim wrote:
> If CMA option is not selected, __alloc_from_contiguous would not be
> called. We don't need to the fallback allocation.
>
> And if CMA option is selected and initialized correctly,
> the cma allocation can fail in case of no-CMA-memory situation.
> I thinks in that case we don't need to the fallback allocation also,
> because it is normal case.
>
> Therefore I think the restriction of CMA size option and make CMA work
> can cover every cases.
Wait, you just wrote that if CMA is not initialised correctly, it's fine
for atomic pool initialisation to fail, but if CMA size is initialised
correctly but too small, this is somehow worse situation? I'm a bit
confused to be honest.
IMO, cma=0 command line argument should be supported, as should having
the default CMA size zero. If CMA size is set to zero, kernel should
behave as if CMA was not enabled at compile time.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +--<mpn@...gle.com>--<xmpp:mina86@...ber.org>--ooO--(_)--Ooo--
Download attachment "signature.asc" of type "application/pgp-signature" (836 bytes)
Powered by blists - more mailing lists