[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5514A9AF.30108@lge.com>
Date: Fri, 27 Mar 2015 09:51:59 +0900
From: Gioh Kim <gioh.kim@....com>
To: Mel Gorman <mgorman@...e.de>
CC: akpm@...ux-foundation.org, riel@...hat.com, hannes@...xchg.org,
rientjes@...gle.com, vdavydov@...allels.com,
iamjoonsoo.kim@....com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, gunho.lee@....com
Subject: Re: [RFCv2] mm: page allocation for less fragmentation
2015-03-26 오후 7:28에 Mel Gorman 이(가) 쓴 글:
> On Thu, Mar 26, 2015 at 06:16:22AM +0900, Gioh Kim wrote:
>>
>>
>> 2015-03-25 ?????? 7:56??? Mel Gorman ???(???) ??? ???:
>>> On Wed, Mar 25, 2015 at 11:39:15AM +0900, Gioh Kim wrote:
>>>> My driver allocates more than 40MB pages via alloc_page() at a time and
>>>> maps them at virtual address. Totally it uses 300~400MB pages.
>>>>
>>>> If I run a heavy load test for a few days in 1GB memory system, I cannot allocate even order=3 pages
>>>> because-of the external fragmentation.
>>>>
>>>> I thought I needed a anti-fragmentation solution for my driver.
>>>> But there is no allocation function that considers fragmentation.
>>>> The compaction is not helpful because it is only for movable pages, not unmovable pages.
>>>>
>>>> This patch proposes a allocation function allocates only pages in the same pageblock.
>>>>
>>>
>>> Is this not what CMA is for? Or creating a MOVABLE zone?
>>
>> It's not related to CMA and MOVABLE zone.
>> It's for compaction and anti-fragmentation for any zone.
>>
>
> Create a CMA area, allow your driver to use it use alloc_contig_range.
> As it is, this is creating another contiguous range allocation function
> with no in-kernel users.
>
I'm sorry but I cannot follow your point.
I think this is not contiguous range allocation.
And CMA is not suitable for my driver because it needs fast allocation.
I can move pages into CMA area if I need high-order pages.
But the pages are unmovable types so it would pin the CMA area.
Please let me explain my problem again.
I've been suffering for years from fragmentation via unmovable pages.
Many of them are via graphic driver such as gpu and coder/decoder.
Current kernel compaction is not sufficient with this situation.
Graphic memory of the embedded systems like TV, phone I'm working for is getting bigger.
For instance my platform has 1GB and 300MB~400MB are consumed for graphic processing.
There are two reason:
1. cpu and gpu share memory
2. screen size(resolution) is getting bigger so that icon and ux images also are getting bigger
Therefore I don't need any contigous pages, but less fragmentation page allocation for unmovable pages.
--
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/
Powered by blists - more mailing lists