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(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 4656c0f..d4f1cf2 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c

@@ -1083,10 +1083,7 @@ static struct page **__iommu_alloc_buffer(struct

        int count = size >> PAGE_SHIFT;
        int array_size = count * sizeof(struct page *);

-       if (array_size <= PAGE_SIZE)
-               pages = kzalloc(array_size, gfp);
-       else
-               pages = vzalloc(array_size);
+       pages = kzalloc(array_size, gfp);
        if (!pages)
                return NULL;

@@ -1107,10 +1104,7 @@ static struct page **__iommu_alloc_buffer(struct