From: m.szyprowski@samsung•com (Marek Szyprowski)
To: linux-arm-kernel@lists•infradead.org
Subject: CMA region and highmem
Date: Thu, 21 Aug 2014 11:32:51 +0200 [thread overview]
Message-ID: <53F5BCC3.2060609@samsung.com> (raw)
In-Reply-To: <CAD8Lp47W9UcA7CHSK9xia_b9opLv-5wi_9Omj2DThRo4wYkcNw@mail.gmail.com>
Hello,
On 2014-08-21 11:22, Daniel Drake wrote:
> Thanks Russell for looking into this! I'm also working with a large
> CMA region and had also seen a couple of OOMs which are likely the
> same thing.
>
> This will also allow for larger CMA regions to be allocated as right
> now they were limited to the largest free contiguous chunk of lowmem
> available and that does suffer a small amount of fragmentation at boot
> time.
>
> On Wed, Aug 20, 2014 at 8:03 AM, Marek Szyprowski
> <m.szyprowski@samsung•com> wrote:
>> There is no direct dependecy on low-mem. It was rather a heritage of initial
>> CMA implementation, which by design worked only with lowmem (there was no
>> code to allocate kernel virtual mappings from vmalloc range). The only
>> requirement about CMA regions is to put them entirely either in lowmem or
>> in highmem. I will prepare a patch swtiching default CMA region to highmem
>> if such is available and defined region fits into it.
> Just curious, to complete my understanding here...
>
> If the CMA region is now moved into highmem, when memory is allocated
> with the DMA API, such memory will now use up vmalloc space. Is that
> right?
Yes, you are right.
> In the default 3G/1G split configuration, of the 1G, 240mb is vmalloc
> space by default (and 760mb is lowmem).
>
> So, lets say your patch moves CMA into highmem, and I build a kernel
> with a 512mb CMA allocation.
>
> Now whenever anyone uses the DMA API to allocate from CMA, it will
> only be able to allocate a maximum of 240mb, later allocations will
> then fail due to lack of vmalloc space. Right?
>
> Of course, vmalloc space can be increased, but only at the expenses of
> reducing lowmem.
>
> Thanks for any clarifications!
You are right, but frankly drivers doing large DMA allocations should take
advantage of DMA_ATTR_NO_KERNEL_MAPPING DMA attribute, because all they
usually do is just mapping those buffers to userspace. For a bit complex
example, see drivers/gpu/drm/exynos/exynos_drm_buf.c or
drivers/gpu/drm/msm/msm_drv.c.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
next prev parent reply other threads:[~2014-08-21 9:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 19:18 CMA region and highmem Russell King - ARM Linux
2014-08-20 7:03 ` Marek Szyprowski
2014-08-21 9:22 ` Daniel Drake
2014-08-21 9:32 ` Marek Szyprowski [this message]
2015-01-22 20:55 ` Daniel Drake
2015-01-23 7:26 ` Marek Szyprowski
2014-08-21 9:32 ` Russell King - ARM Linux
2014-10-23 2:10 ` Gregory Fong
2014-10-23 8:55 ` Russell King - ARM Linux
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=53F5BCC3.2060609@samsung.com \
--to=m.szyprowski@samsung$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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