linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KyongHo Cho <pullip.cho@samsung.com>
To: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: "m.szyprowski@samsung.com" <m.szyprowski@samsung.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kyungmin.park@samsung.com" <kyungmin.park@samsung.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"chunsang.jeong@linaro.org" <chunsang.jeong@linaro.org>,
	Krishna Reddy <vdumpa@nvidia.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"subashrp@gmail.com" <subashrp@gmail.com>,
	"minchan@kernel.org" <minchan@kernel.org>
Subject: [RFC 2/4] ARM: dma-mapping: IOMMU allocates pages from pool with GFP_ATOMIC
Date: Thu, 23 Aug 2012 12:57:01 +0900	[thread overview]
Message-ID: <CAHQjnOMnGMTgrcK+aNsn1OuePdLbPyWkOJoArhUJes4zkwzHAQ@mail.gmail.com> (raw)
In-Reply-To: <20120822.163648.3800987367886904.hdoyu@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 3167 bytes --]

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 <hdoyu@nvidia.com> wrote:
> Hi,
>
> KyongHo Cho <pullip.cho@samsung.com> 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 <hdoyu@nvidia.com>
> 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 <hdoyu@nvidia.com>
> ---
>  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
device *dev, size_t size,
>         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
device *dev, size_t size,
>
>         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@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a hrefmailto:"dont@kvack.org"> email@kvack.org </a>

[-- Attachment #2: Type: text/html, Size: 4112 bytes --]

  parent reply	other threads:[~2012-08-23  3:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-22 10:20 [RFC 0/4] ARM: dma-mapping: IOMMU atomic allocation Hiroshi Doyu
2012-08-22 10:20 ` [RFC 1/4] ARM: dma-mapping: Refactor out to introduce __alloc_fill_pages Hiroshi Doyu
2012-08-22 10:20 ` [RFC 2/4] ARM: dma-mapping: IOMMU allocates pages from pool with GFP_ATOMIC Hiroshi Doyu
2012-08-22 12:29   ` Marek Szyprowski
2012-08-22 12:52     ` Hiroshi Doyu
2012-08-22 12:47   ` KyongHo Cho
2012-08-22 13:36     ` Hiroshi Doyu
2012-08-23  3:49       ` Minchan Kim
2012-08-23  3:57       ` KyongHo Cho [this message]
2012-08-23  5:58       ` Marek Szyprowski
2012-08-23  6:15         ` Hiroshi Doyu
2012-08-23  7:52           ` Marek Szyprowski
2012-08-22 10:20 ` [RFC 3/4] ARM: dma-mapping: Return cpu addr when dma_alloc(GFP_ATOMIC) Hiroshi Doyu
2012-08-22 10:20 ` [RFC 4/4] ARM: dma-mapping: dma_{alloc,free}_coherent with empty attrs Hiroshi Doyu
2012-08-22 12:04 ` [RFC 0/4] ARM: dma-mapping: IOMMU atomic allocation Marek Szyprowski
2012-08-22 14:44   ` Hiroshi Doyu

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=CAHQjnOMnGMTgrcK+aNsn1OuePdLbPyWkOJoArhUJes4zkwzHAQ@mail.gmail.com \
    --to=pullip.cho@samsung.com \
    --cc=arnd@arndb.de \
    --cc=chunsang.jeong@linaro.org \
    --cc=hdoyu@nvidia.com \
    --cc=konrad.wilk@oracle.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=minchan@kernel.org \
    --cc=subashrp@gmail.com \
    --cc=vdumpa@nvidia.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).