All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.