There's possibility that this attrs be used later to set.
Signed-off-by: Hiroshi Doyu <redacted>
---
arch/arm/include/asm/dma-mapping.h | 21 +++++++++++++++++----
1 files changed, 17 insertions(+), 4 deletions(-)
Makes use of the same atomic pool from DMA, and skips kernel page
mapping which can involves sleep'able operation at allocating a kernel
page table.
Signed-off-by: Hiroshi Doyu <redacted>
---
arch/arm/mm/dma-mapping.c | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
From: Marek Szyprowski <m.szyprowski@samsung.com> Date: 2012-08-22 12:04:47
Hi Hiroshi,
On Wednesday, August 22, 2012 12:20 PM Hiroshi Doyu wrote:
The commit e9da6e9 "ARM: dma-mapping: remove custom consistent dma
region" breaks the compatibility with existing drivers. This causes
the following kernel oops(*1). That driver has called dma_pool_alloc()
to allocate memory from the interrupt context, and it hits
BUG_ON(in_interrpt()) in "get_vm_area_caller()". This patch seris
fixes this problem with making use of the pre-allocate atomic memory
pool which DMA is using in the same way as DMA does now.
Any comment would be really appreciated.
I was working on the similar patches, but You were faster. ;-)
Basically the patch no 1 and 2 are fine, but I don't like the changes proposed in
patch 3 and 4. You should not alter the attributes provided by the user nor make any
assumptions that such attributes has been provided - drivers are allowed to call
dma_alloc_attrs() directly. Please rework your patches to avoid such approach.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
From: Marek Szyprowski <m.szyprowski@samsung.com> Date: 2012-08-22 12:30:10
Hello,
On Wednesday, August 22, 2012 12:20 PM Hiroshi Doyu wrote:
quoted hunk
Makes use of the same atomic pool from DMA, and skips kernel page
mapping which can involves sleep'able operation at allocating a kernel
page table.
Signed-off-by: Hiroshi Doyu <redacted>
---
arch/arm/mm/dma-mapping.c | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
From: KyongHo Cho <hidden> Date: 2012-08-22 12:47:03
Hi.
vzalloc() call in __iommu_alloc_buffer() also causes BUG() in atomic
context.
On Wed, Aug 22, 2012 at 7:20 PM, Hiroshi Doyu [off-list ref] wrote:
quoted hunk
Makes use of the same atomic pool from DMA, and skips kernel page
mapping which can involves sleep'able operation at allocating a kernel
page table.
Signed-off-by: Hiroshi Doyu <redacted>
---
arch/arm/mm/dma-mapping.c | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
if (!pages)
return NULL;
- err = __alloc_fill_pages(&pages, count, gfp);
- if (err)
- goto error
+ if (gfp & GFP_ATOMIC) {
+ struct page *page;
+ int i;
+ void *addr = __alloc_from_pool(size, &page);
+ if (!addr)
+ goto err_out;
+
+ for (i = 0; i < count; i++)
+ pages[i] = page + i;
+ } else {
+ int err = __alloc_fill_pages(&pages, count, gfp);
+ if (err)
+ goto error;
+ }
return pages;
error:
@@ -1055,6 +1065,10 @@ static int __iommu_free_buffer(struct device *dev,
struct page **pages, size_t s
int count = size >> PAGE_SHIFT;
int array_size = count * sizeof(struct page *);
int i;
+
+ if (__free_from_pool(page_address(pages[0]), size))
+ return 0;
+
for (i = 0; i < count; i++)
if (pages[i])
__free_pages(pages[i], 0);
--
1.7.5.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo at kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
Marek Szyprowski [off-list ref] wrote @ Wed, 22 Aug 2012 14:29:47 +0200:
Hello,
On Wednesday, August 22, 2012 12:20 PM Hiroshi Doyu wrote:
quoted
Makes use of the same atomic pool from DMA, and skips kernel page
mapping which can involves sleep'able operation at allocating a kernel
page table.
Signed-off-by: Hiroshi Doyu <redacted>
---
arch/arm/mm/dma-mapping.c | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
Hi,
KyongHo Cho [off-list ref] wrote @ Wed, 22 Aug 2012 14:47:00 +0200:
vzalloc() call in __iommu_alloc_buffer() also causes BUG() in atomic context.
Right.
I've been thinking that kzalloc() may be enough here, since
vzalloc() was introduced to avoid allocation failure for big chunk of
memory, but I think that it's unlikely that the number of page array
can be so big. So I propose to drop vzalloc() here, and just simply to
use kzalloc only as below(*1).
For example,
1920(H) x 1080(W) x 4(bytes) ~= 8MiB
For 8 MiB buffer,
8(MiB) * 1024 = 8192(KiB)
8192(KiB) / 4(KiB/page) = 2048 pages
sizeof(struct page *) = 4 bytes
2048(pages) * 4(bytes/page) = 8192(bytes) = 8(KiB)
8(KiB) / 4(KiB/page) = 2 pages
If the above estimation is right(I hope;)), the necessary pages are
_at most_ 2 pages. If the system gets into the situation to fail to
allocate 2 contiguous pages, that's real the problem. I guess that
that kind of fragmentation problem would be solved with page migration
or something, especially nowadays devices are getting larger memories.
*1:
From a613c40d1b3d4fb1577cdb0807a74e8dbd08a3e6 Mon Sep 17 00:00:00 2001
From: Hiroshi Doyu <redacted>
Date: Wed, 22 Aug 2012 16:25:54 +0300
Subject: [PATCH 1/1] ARM: dma-mapping: Use only kzalloc without vzalloc
Use only kzalloc for atomic allocation.
Signed-off-by: Hiroshi Doyu <redacted>
---
arch/arm/mm/dma-mapping.c | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
Hi Marek,
Marek Szyprowski [off-list ref] wrote @ Wed, 22 Aug 2012 14:04:26 +0200:
Hi Hiroshi,
On Wednesday, August 22, 2012 12:20 PM Hiroshi Doyu wrote:
quoted
The commit e9da6e9 "ARM: dma-mapping: remove custom consistent dma
region" breaks the compatibility with existing drivers. This causes
the following kernel oops(*1). That driver has called dma_pool_alloc()
to allocate memory from the interrupt context, and it hits
BUG_ON(in_interrpt()) in "get_vm_area_caller()". This patch seris
fixes this problem with making use of the pre-allocate atomic memory
pool which DMA is using in the same way as DMA does now.
Any comment would be really appreciated.
I was working on the similar patches, but You were faster. ;-)
Thank you for reviewing my patches.
Basically the patch no 1 and 2 are fine, but I don't like the changes proposed in
patch 3 and 4. You should not alter the attributes provided by the user nor make any
assumptions that such attributes has been provided - drivers are allowed to call
dma_alloc_attrs() directly. Please rework your patches to avoid such
approach.
Sure. I'll send the series again later.
Instead of making use of DMA_ATTR_NO_KERNEL_MAPPING, I use the
following "__in_atomic_pool()" to see if buffer comes from atomic or
not at freeing.
From cdf8621fd0876f3e56a55885c27e363893df2c98 Mon Sep 17 00:00:00 2001
From: Hiroshi Doyu <redacted>
Date: Wed, 22 Aug 2012 17:26:29 +0300
Subject: [PATCH 1/1] ARM: dma-mapping: Refactor out to introduce
__in_atomic_pool
Check the given range("start", "size") is included in "atomic_pool" or not.
Signed-off-by: Hiroshi Doyu <redacted>
---
arch/arm/mm/dma-mapping.c | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
From: Minchan Kim <minchan@kernel.org> Date: 2012-08-23 03:49:11
On Wed, Aug 22, 2012 at 03:36:48PM +0200, Hiroshi Doyu wrote:
Hi,
KyongHo Cho [off-list ref] wrote @ Wed, 22 Aug 2012 14:47:00 +0200:
quoted
vzalloc() call in __iommu_alloc_buffer() also causes BUG() in atomic context.
Right.
I've been thinking that kzalloc() may be enough here, since
vzalloc() was introduced to avoid allocation failure for big chunk of
memory, but I think that it's unlikely that the number of page array
can be so big. So I propose to drop vzalloc() here, and just simply to
use kzalloc only as below(*1).
For example,
1920(H) x 1080(W) x 4(bytes) ~= 8MiB
For 8 MiB buffer,
8(MiB) * 1024 = 8192(KiB)
8192(KiB) / 4(KiB/page) = 2048 pages
sizeof(struct page *) = 4 bytes
2048(pages) * 4(bytes/page) = 8192(bytes) = 8(KiB)
8(KiB) / 4(KiB/page) = 2 pages
If the above estimation is right(I hope;)), the necessary pages are
_at most_ 2 pages. If the system gets into the situation to fail to
allocate 2 contiguous pages, that's real the problem. I guess that
that kind of fragmentation problem would be solved with page migration
or something, especially nowadays devices are getting larger memories.
In atomic context, VM have no choice except relying on kswapd so
high order allocation can fail easily when memory fragementation
is high.
--
Kind regards,
Minchan Kim
From: KyongHo Cho <hidden> Date: 2012-08-23 03:57:03
Hi.
We have faced with WQXGA(2560x1600) support and framebuffers become
dramatically larger.
Moreover, high resolution camera sensors also press memory use more than
the screen size.
However, I think that it is enough with your change because allocation
failure of several
contiguous pages also shows that the system don't have enough memory.
On Wed, Aug 22, 2012 at 10:36 PM, Hiroshi Doyu [off-list ref] wrote:
Hi,
KyongHo Cho [off-list ref] wrote @ Wed, 22 Aug 2012 14:47:00
+0200:
quoted
vzalloc() call in __iommu_alloc_buffer() also causes BUG() in atomic
context.
quoted hunk
Right.
I've been thinking that kzalloc() may be enough here, since
vzalloc() was introduced to avoid allocation failure for big chunk of
memory, but I think that it's unlikely that the number of page array
can be so big. So I propose to drop vzalloc() here, and just simply to
use kzalloc only as below(*1).
For example,
1920(H) x 1080(W) x 4(bytes) ~= 8MiB
For 8 MiB buffer,
8(MiB) * 1024 = 8192(KiB)
8192(KiB) / 4(KiB/page) = 2048 pages
sizeof(struct page *) = 4 bytes
2048(pages) * 4(bytes/page) = 8192(bytes) = 8(KiB)
8(KiB) / 4(KiB/page) = 2 pages
If the above estimation is right(I hope;)), the necessary pages are
_at most_ 2 pages. If the system gets into the situation to fail to
allocate 2 contiguous pages, that's real the problem. I guess that
that kind of fragmentation problem would be solved with page migration
or something, especially nowadays devices are getting larger memories.
*1:
From a613c40d1b3d4fb1577cdb0807a74e8dbd08a3e6 Mon Sep 17 00:00:00 2001
From: Hiroshi Doyu <redacted>
Date: Wed, 22 Aug 2012 16:25:54 +0300
Subject: [PATCH 1/1] ARM: dma-mapping: Use only kzalloc without vzalloc
Use only kzalloc for atomic allocation.
Signed-off-by: Hiroshi Doyu <redacted>
---
arch/arm/mm/dma-mapping.c | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
return pages;
error:
- if (array_size <= PAGE_SIZE)
- kfree(pages);
- else
- vfree(pages);
+ kfree(pages);
return NULL;
}
--
1.7.5.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo at kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a hrefmailto:"dont@kvack.org"> email at kvack.org </a>
From: Marek Szyprowski <m.szyprowski@samsung.com> Date: 2012-08-23 05:58:57
Hello,
On Wednesday, August 22, 2012 3:37 PM Hiroshi Doyu wrote:
KyongHo Cho [off-list ref] wrote @ Wed, 22 Aug 2012 14:47:00 +0200:
quoted
vzalloc() call in __iommu_alloc_buffer() also causes BUG() in atomic context.
Right.
I've been thinking that kzalloc() may be enough here, since
vzalloc() was introduced to avoid allocation failure for big chunk of
memory, but I think that it's unlikely that the number of page array
can be so big. So I propose to drop vzalloc() here, and just simply to
use kzalloc only as below(*1).
We already had a discussion about this, so I don't think it makes much sense to
change it back to kzalloc. This vmalloc() call won't hurt anyone. It should not
be considered a problem for atomic allocations, because no sane driver will try
to allocate buffers larger than a dozen KiB with GFP_ATOMIC flag. I would call
such try a serious bug, which we should not care here.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
Hi,
On Thu, 23 Aug 2012 07:58:34 +0200
Marek Szyprowski [off-list ref] wrote:
Hello,
On Wednesday, August 22, 2012 3:37 PM Hiroshi Doyu wrote:
quoted
KyongHo Cho [off-list ref] wrote @ Wed, 22 Aug 2012 14:47:00 +0200:
quoted
vzalloc() call in __iommu_alloc_buffer() also causes BUG() in atomic context.
Right.
I've been thinking that kzalloc() may be enough here, since
vzalloc() was introduced to avoid allocation failure for big chunk of
memory, but I think that it's unlikely that the number of page array
can be so big. So I propose to drop vzalloc() here, and just simply to
use kzalloc only as below(*1).
We already had a discussion about this, so I don't think it makes much sense to
change it back to kzalloc. This vmalloc() call won't hurt anyone. It should not
be considered a problem for atomic allocations, because no sane driver will try
to allocate buffers larger than a dozen KiB with GFP_ATOMIC flag. I would call
such try a serious bug, which we should not care here.
Ok, I've already sent v2 just now, where, instead of changing it back,
just with GFP_ATOMIC, kzalloc() would be selected, just in case. I guess
that this would be ok(a bit safer?)
From: Marek Szyprowski <m.szyprowski@samsung.com> Date: 2012-08-23 07:52:30
Hi Hiroshi,
On Thursday, August 23, 2012 8:15 AM Hiroshi Doyu wrote:
On Thu, 23 Aug 2012 07:58:34 +0200
Marek Szyprowski [off-list ref] wrote:
quoted
Hello,
On Wednesday, August 22, 2012 3:37 PM Hiroshi Doyu wrote:
quoted
KyongHo Cho [off-list ref] wrote @ Wed, 22 Aug 2012 14:47:00 +0200:
quoted
vzalloc() call in __iommu_alloc_buffer() also causes BUG() in atomic context.
Right.
I've been thinking that kzalloc() may be enough here, since
vzalloc() was introduced to avoid allocation failure for big chunk of
memory, but I think that it's unlikely that the number of page array
can be so big. So I propose to drop vzalloc() here, and just simply to
use kzalloc only as below(*1).
We already had a discussion about this, so I don't think it makes much sense to
change it back to kzalloc. This vmalloc() call won't hurt anyone. It should not
be considered a problem for atomic allocations, because no sane driver will try
to allocate buffers larger than a dozen KiB with GFP_ATOMIC flag. I would call
such try a serious bug, which we should not care here.
Ok, I've already sent v2 just now, where, instead of changing it back,
just with GFP_ATOMIC, kzalloc() would be selected, just in case. I guess
that this would be ok(a bit safer?)
I've posted some comments to v2. If you agree with my suggestion, no changes around
those vmalloc() calls will be needed.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center