CMA region and highmem

CMA region and highmem

[Russell King - ARM Linux]

Marek,

Is there a reason that CMA only steals memory from lowmem, and does
not allocate from highmem?

The reason I ask is that this morning, I was greeted by this excellent
OOM on one of my platforms.  It has 2G of memory, and no real DMA
restrictions, and with much of the memory still available, it OOM'd
because I need a relatively large CMA block.

If CMA were pushed into highmem, this OOM would not have happened.

Please don't mention anything suggesting that the reason it's in lowmem
is because of DMA-able memory restrictions - that's a totally bogus and
insane argument.  The highmem/lowmem split is purely a software thing
and has nothing to do with the hardware at all.  I'll illustrate:

 Take a platform with 2G of memory.  You configure it with PAGE_OFFSET
 at 3GB.  You end up with about 760MB of lowmem, the rest as highmem.
 Let's say (for the sake of argument) that you rely on that split,
 beacuse you have devices which don't work with the second 1GB of
 memory.

 Now I build that same kernel, but configure PAGE_OFFSET at 1GB.  Bingo,
 all 2G of memory is now mapped as lowmem, and there is nothing stopping
 any of the 2G of memory being handed out for DMA purposes.

Therefore, talking about highmem/lowmem in the same sentence as DMA-able
memory is totally wrong.

Anyway, back to the OOM:

xdg-screensaver invoked oom-killer: gfp_mask=0x4d0, order=2, oom_score_adj=0
CPU: 2 PID: 6476 Comm: xdg-screensaver Not tainted 3.16.0+ #1322
...
[<c001c8e8>] (pgd_alloc) from [<c00237b8>] (mm_init.isra.51+0xc0/0x120)
...
Mem-info:
Normal per-cpu:
CPU    0: hi:  186, btch:  31 usd:  29
CPU    1: hi:  186, btch:  31 usd:   0
CPU    2: hi:  186, btch:  31 usd:   0
CPU    3: hi:  186, btch:  31 usd:   0
HighMem per-cpu:
CPU    0: hi:  186, btch:  31 usd:   0
CPU    1: hi:  186, btch:  31 usd:  21
CPU    2: hi:  186, btch:  31 usd:   0
CPU    3: hi:  186, btch:  31 usd:   0
active_anon:47933 inactive_anon:2583 isolated_anon:0
 active_file:16171 inactive_file:71321 isolated_file:0
 unevictable:0 dirty:0 writeback:0 unstable:0
 free:244622 slab_reclaimable:3605 slab_unreclaimable:95994
 mapped:21360 shmem:5230 pagetables:1176 bounce:0
 free_cma:37697
Normal free:159400kB min:3440kB low:4300kB high:5160kB active_anon:54336kB
 inactive_anon:2580kB active_file:56kB inactive_file:204kB unevictable:0kB
 isolated(anon):0kB isolated(file):0kB present:778240kB managed:740044kB
 mlocked:0kB dirty:0kB writeback:0kB mapped:5336kB shmem:5428kB
 slab_reclaimable:14420kB slab_unreclaimable:383976kB kernel_stack:2512kB
 pagetables:1088kB unstable:0kB bounce:0kB free_cma:150788kB
 writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 10304 10304
HighMem free:818228kB min:512kB low:2044kB high:3576kB active_anon:138352kB
 inactive_anon:7752kB active_file:64692kB inactive_file:285204kB unevictable:0kB
 isolated(anon):0kB isolated(file):0kB present:1318912kB managed:1318912kB
 mlocked:0kB dirty:0kB writeback:0kB mapped:80072kB shmem:15492kB
 slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB
 pagetables:3636kB unstable:0kB bounce:0kB free_cma:0kB
 writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
Normal: 117*4kB (UEMC) 959*8kB (UEMC) 2*16kB (C) 2*32kB
 (C) 2*64kB (C) 0*128kB 0*256kB 0*512kB 1*1024kB (C) 1*2048kB (C)
 36*4096kB (C) = 158892kB
HighMem: 32*4kB (UM) 75*8kB (UM) 633*16kB (UM) 377*32kB (UM) 191*64kB
 (UM) 86*128kB (UM) 40*256kB (M) 19*512kB (M) 14*1024kB (UM) 6*2048kB
 (UM) 177*4096kB (MR) = 817736kB
92769 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
524288 pages of RAM
244139 free pages
9549 reserved pages
27079 slab pages
55230910 pages shared
0 pages swap cached
...
Out of memory: Kill process 3460 (vlc) score 38 or sacrifice child
Killed process 3460 (vlc) total-vm:278340kB, anon-rss:30360kB, file-rss:48988kB

As you can see, there's plenty of precious lowmem still available, but
because we only have 760MB of lowmem, from which we steal 256MB for
CMA, this leaves around 500MB of lowmem free - and that puts quite a
lot of pressure on lowmem.  Meanwhile, we have oodles of highmem still
available which would be better suited to CMA - especially as CMA would
not have to do dance around changing the page tables.

Any thoughts?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

CMA region and highmem

[Marek Szyprowski]

Hello,

On 2014-08-13 21:18, Russell King - ARM Linux wrote:
> Marek,
>
> Is there a reason that CMA only steals memory from lowmem, and does
> not allocate from highmem?
>
> The reason I ask is that this morning, I was greeted by this excellent
> OOM on one of my platforms.  It has 2G of memory, and no real DMA
> restrictions, and with much of the memory still available, it OOM'd
> because I need a relatively large CMA block.
>
> If CMA were pushed into highmem, this OOM would not have happened.
>
> Please don't mention anything suggesting that the reason it's in lowmem
> is because of DMA-able memory restrictions - that's a totally bogus and
> insane argument.  The highmem/lowmem split is purely a software thing
> and has nothing to do with the hardware at all.  I'll illustrate:
>
>   Take a platform with 2G of memory.  You configure it with PAGE_OFFSET
>   at 3GB.  You end up with about 760MB of lowmem, the rest as highmem.
>   Let's say (for the sake of argument) that you rely on that split,
>   beacuse you have devices which don't work with the second 1GB of
>   memory.
>
>   Now I build that same kernel, but configure PAGE_OFFSET at 1GB.  Bingo,
>   all 2G of memory is now mapped as lowmem, and there is nothing stopping
>   any of the 2G of memory being handed out for DMA purposes.
>
> Therefore, talking about highmem/lowmem in the same sentence as DMA-able
> memory is totally wrong.
>
> Anyway, back to the OOM:
...
> As you can see, there's plenty of precious lowmem still available, but
> because we only have 760MB of lowmem, from which we steal 256MB for
> CMA, this leaves around 500MB of lowmem free - and that puts quite a
> lot of pressure on lowmem.  Meanwhile, we have oodles of highmem still
> available which would be better suited to CMA - especially as CMA would
> not have to do dance around changing the page tables.
>
> Any thoughts?

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.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

CMA region and highmem

[Daniel Drake]

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?

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!
Daniel

CMA region and highmem

[Marek Szyprowski]

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

CMA region and highmem

[Russell King - ARM Linux]

On Thu, Aug 21, 2014 at 10:22:35AM +0100, Daniel Drake wrote:
> 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?
> 
> 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.

Correct.  So, if you need more space than is available, the options are:

- use an API which does not map into virtual space when it is not required.
  (Unfortunately, the DMA API assumes that if you want DMA memory, you
  also want it mapped as well.)  This avoids unnecessary wastage of kernel
  memory space.

- reduce PAGE_OFFSET to give yourself more kernel memory space at the
  expense of reduced userspace.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

CMA region and highmem

[Gregory Fong]

Hi Russell,

On Wed, Aug 13, 2014 at 12:18 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> [...]
> The reason I ask is that this morning, I was greeted by this excellent
> OOM on one of my platforms.  It has 2G of memory, and no real DMA
> restrictions, and with much of the memory still available, it OOM'd
> because I need a relatively large CMA block.
> [...]
> xdg-screensaver invoked oom-killer: gfp_mask=0x4d0, order=2, oom_score_adj=0
> CPU: 2 PID: 6476 Comm: xdg-screensaver Not tainted 3.16.0+ #1322
> ...
> [<c001c8e8>] (pgd_alloc) from [<c00237b8>] (mm_init.isra.51+0xc0/0x120)
> ...
> Mem-info:
> Normal per-cpu:
> CPU    0: hi:  186, btch:  31 usd:  29
> CPU    1: hi:  186, btch:  31 usd:   0
> CPU    2: hi:  186, btch:  31 usd:   0
> CPU    3: hi:  186, btch:  31 usd:   0
> HighMem per-cpu:
> CPU    0: hi:  186, btch:  31 usd:   0
> CPU    1: hi:  186, btch:  31 usd:  21
> CPU    2: hi:  186, btch:  31 usd:   0
> CPU    3: hi:  186, btch:  31 usd:   0
> active_anon:47933 inactive_anon:2583 isolated_anon:0
>  active_file:16171 inactive_file:71321 isolated_file:0
>  unevictable:0 dirty:0 writeback:0 unstable:0
>  free:244622 slab_reclaimable:3605 slab_unreclaimable:95994
>  mapped:21360 shmem:5230 pagetables:1176 bounce:0
>  free_cma:37697
> Normal free:159400kB min:3440kB low:4300kB high:5160kB active_anon:54336kB
>  inactive_anon:2580kB active_file:56kB inactive_file:204kB unevictable:0kB
>  isolated(anon):0kB isolated(file):0kB present:778240kB managed:740044kB
>  mlocked:0kB dirty:0kB writeback:0kB mapped:5336kB shmem:5428kB
>  slab_reclaimable:14420kB slab_unreclaimable:383976kB kernel_stack:2512kB
>  pagetables:1088kB unstable:0kB bounce:0kB free_cma:150788kB
>  writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 10304 10304
> HighMem free:818228kB min:512kB low:2044kB high:3576kB active_anon:138352kB
>  inactive_anon:7752kB active_file:64692kB inactive_file:285204kB unevictable:0kB
>  isolated(anon):0kB isolated(file):0kB present:1318912kB managed:1318912kB
>  mlocked:0kB dirty:0kB writeback:0kB mapped:80072kB shmem:15492kB
>  slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB
>  pagetables:3636kB unstable:0kB bounce:0kB free_cma:0kB
>  writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0
> Normal: 117*4kB (UEMC) 959*8kB (UEMC) 2*16kB (C) 2*32kB
>  (C) 2*64kB (C) 0*128kB 0*256kB 0*512kB 1*1024kB (C) 1*2048kB (C)
>  36*4096kB (C) = 158892kB
> HighMem: 32*4kB (UM) 75*8kB (UM) 633*16kB (UM) 377*32kB (UM) 191*64kB
>  (UM) 86*128kB (UM) 40*256kB (M) 19*512kB (M) 14*1024kB (UM) 6*2048kB
>  (UM) 177*4096kB (MR) = 817736kB
> 92769 total pagecache pages
> 0 pages in swap cache
> Swap cache stats: add 0, delete 0, find 0/0
> Free swap  = 0kB
> Total swap = 0kB
> 524288 pages of RAM
> 244139 free pages
> 9549 reserved pages
> 27079 slab pages
> 55230910 pages shared
> 0 pages swap cached
> ...
> Out of memory: Kill process 3460 (vlc) score 38 or sacrifice child
> Killed process 3460 (vlc) total-vm:278340kB, anon-rss:30360kB, file-rss:48988kB
> [...]
> As you can see, there's plenty of precious lowmem still available, but
> because we only have 760MB of lowmem, from which we steal 256MB for
> CMA, this leaves around 500MB of lowmem free - and that puts quite a
> lot of pressure on lowmem.  Meanwhile, we have oodles of highmem still
> available which would be better suited to CMA - especially as CMA would
> not have to do dance around changing the page tables.

I am running into a similar issue with CMA, and am still confused: how
is it that even though there's ~160 MB of lowmem free shown above, and
based on

> Normal: 117*4kB (UEMC) 959*8kB (UEMC) 2*16kB (C) 2*32kB
>  (C) 2*64kB (C) 0*128kB 0*256kB 0*512kB 1*1024kB (C) 1*2048kB (C)
>  36*4096kB (C) = 158892kB

it doesn't look like the fragmentation is _too_ terrible, an OOM still
happens?  Since this didn't seem surprising to you, I'm thinking my
understanding might be wrong, and was wondering if you might be able
to help me understand how an OOM like this happens with such a large
amount of lowmem still free.

Thanks and regards,
Gregory

CMA region and highmem

[Russell King - ARM Linux]

On Wed, Oct 22, 2014 at 07:10:58PM -0700, Gregory Fong wrote:
> Hi Russell,
> 
> On Wed, Aug 13, 2014 at 12:18 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > [...]
> > The reason I ask is that this morning, I was greeted by this excellent
> > OOM on one of my platforms.  It has 2G of memory, and no real DMA
> > restrictions, and with much of the memory still available, it OOM'd
> > because I need a relatively large CMA block.
> > [...]
> > xdg-screensaver invoked oom-killer: gfp_mask=0x4d0, order=2, oom_score_adj=0

order=2 => 16K

> > Normal: 117*4kB (UEMC) 959*8kB (UEMC) 2*16kB (C) 2*32kB
> >  (C) 2*64kB (C) 0*128kB 0*256kB 0*512kB 1*1024kB (C) 1*2048kB (C)
> >  36*4096kB (C) = 158892kB
> 
> it doesn't look like the fragmentation is _too_ terrible, an OOM still
> happens?  Since this didn't seem surprising to you, I'm thinking my
> understanding might be wrong, and was wondering if you might be able
> to help me understand how an OOM like this happens with such a large
> amount of lowmem still free.

for 16K and above, all the pages are marked with "C", which means they
are CMA pages.  All other types (unmovable, reclaimable, movable) are
exhausted.

The gfp flags were GFP_KERNEL | __GFP_REPEAT.  Mobility grouping is on,
but allocflags_to_migratetype() returns MIGRATE_UNMOVABLE for this.

The fallbacks for MIGRATE_UNMOVABLE are:

[MIGRATE_UNMOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE, MIGRATE_RESERVE }

which does not allow it to take from CMA.

The only migration type which is allowed to fallback to CMA is:

[MIGRATE_MOVABLE] = { MIGRATE_CMA, MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE, MIGRATE_RESERVE },

which you get with having the "__GFP_MOVABLE" gfp bit set.  Hence,
GFP_KERNEL allocations never allocate from CMA.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

CMA region and highmem

[Daniel Drake]

On Thu, Aug 21, 2014 at 3:32 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> 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.

Thanks again for the insight here. Revisiting this topic now:

Looking at DMA_ATTR_NO_KERNEL_MAPPING in latest linus git, this only
seems to be implemented for IOMMU setups.
On other setups this flag seems to be ignored, so on such setups, your
change that tends to place the CMA region in high memory now puts
pressure on the vmalloc area even when the driver asked for
NO_KERNEL_MAPPING.

Is there a good reason why the non-IOMMU codepath doesn't obey
DMA_ATTR_NO_KERNEL_MAPPING? We ran a quick experiment here
implementing this (i.e. just bailing out of __alloc_from_contiguous
before mapping the memory into kernel space) and it seems to work.

Daniel

CMA region and highmem

[Marek Szyprowski]

Hello,

On 2015-01-22 21:55, Daniel Drake wrote:
> On Thu, Aug 21, 2014 at 3:32 AM, Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> 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.
> Thanks again for the insight here. Revisiting this topic now:
>
> Looking at DMA_ATTR_NO_KERNEL_MAPPING in latest linus git, this only
> seems to be implemented for IOMMU setups.
> On other setups this flag seems to be ignored, so on such setups, your
> change that tends to place the CMA region in high memory now puts
> pressure on the vmalloc area even when the driver asked for
> NO_KERNEL_MAPPING.
>
> Is there a good reason why the non-IOMMU codepath doesn't obey
> DMA_ATTR_NO_KERNEL_MAPPING?

No, it simply has not been implemented yet. Mainly because initially CMA
regions were allocated in low memory and all my development boards that time
didn't have enough memory to experiment with high mem...

> We ran a quick experiment here
> implementing this (i.e. just bailing out of __alloc_from_contiguous
> before mapping the memory into kernel space) and it seems to work.

Right. This should be enough. Feel free to submit a patch.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland