From: Gioh Kim <gioh.kim@lge.com>
To: Mel Gorman <mgorman@suse.de>
Cc: akpm@linux-foundation.org, riel@redhat.com, hannes@cmpxchg.org,
rientjes@google.com, vdavydov@parallels.com,
iamjoonsoo.kim@lge.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, gunho.lee@lge.com
Subject: Re: [RFCv2] mm: page allocation for less fragmentation
Date: Fri, 27 Mar 2015 09:51:59 +0900 [thread overview]
Message-ID: <5514A9AF.30108@lge.com> (raw)
In-Reply-To: <20150326102803.GL4701@suse.de>
2015-03-26 i??i?? 7:28i?? Mel Gorman i?'(e??) i?' e,?:
> 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, 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>
next prev parent reply other threads:[~2015-03-27 0:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-25 2:39 [RFCv2] mm: page allocation for less fragmentation Gioh Kim
2015-03-25 10:56 ` Mel Gorman
2015-03-25 21:16 ` Gioh Kim
2015-03-26 10:28 ` Mel Gorman
2015-03-27 0:51 ` Gioh Kim [this message]
2015-03-25 22:16 ` Vlastimil Babka
2015-03-25 23:25 ` Gioh Kim
2015-04-01 12:05 ` Vlastimil Babka
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=5514A9AF.30108@lge.com \
--to=gioh.kim@lge.com \
--cc=akpm@linux-foundation.org \
--cc=gunho.lee@lge.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=vdavydov@parallels.com \
/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;
as well as URLs for NNTP newsgroup(s).