From patchwork Wed Aug 22 13:36:48 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hiroshi DOYU X-Patchwork-Id: 1361331 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork2.kernel.org (Postfix) with ESMTP id 21777DF280 for ; Wed, 22 Aug 2012 13:40:52 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1T4B7d-0006vC-8h; Wed, 22 Aug 2012 13:37:25 +0000 Received: from hqemgate04.nvidia.com ([216.228.121.35]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1T4B7T-0006rD-1Y for linux-arm-kernel@lists.infradead.org; Wed, 22 Aug 2012 13:37:19 +0000 Received: from hqnvupgp08.nvidia.com (Not Verified[216.228.121.13]) by hqemgate04.nvidia.com id ; Wed, 22 Aug 2012 06:36:16 -0700 Received: from hqemhub03.nvidia.com ([172.17.108.22]) by hqnvupgp08.nvidia.com (PGP Universal service); Wed, 22 Aug 2012 06:36:55 -0700 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Wed, 22 Aug 2012 06:36:55 -0700 Received: from deemhub02.nvidia.com (10.21.69.138) by hqemhub03.nvidia.com (172.20.150.15) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 22 Aug 2012 06:36:54 -0700 Received: from DEMAIL01.nvidia.com ([10.21.69.140]) by deemhub02.nvidia.com ([10.21.69.138]) with mapi; Wed, 22 Aug 2012 15:36:50 +0200 From: Hiroshi Doyu To: "pullip.cho@samsung.com" Date: Wed, 22 Aug 2012 15:36:48 +0200 Subject: Re: [RFC 2/4] ARM: dma-mapping: IOMMU allocates pages from pool with GFP_ATOMIC Thread-Topic: [RFC 2/4] ARM: dma-mapping: IOMMU allocates pages from pool with GFP_ATOMIC Thread-Index: Ac2Aay6W1IqltmFFRWaC/1lscM4zfg== Message-ID: <20120822.163648.3800987367886904.hdoyu@nvidia.com> References: <1345630830-9586-1-git-send-email-hdoyu@nvidia.com><1345630830-9586-3-git-send-email-hdoyu@nvidia.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-nvconfidentiality: public acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -7.1 (-------) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-7.1 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [216.228.121.35 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: "linux@arm.linux.org.uk" , "arnd@arndb.de" , "konrad.wilk@oracle.com" , "chunsang.jeong@linaro.org" , "minchan@kernel.org" , "linux-kernel@vger.kernel.org" , "subashrp@gmail.com" , "linaro-mm-sig@lists.linaro.org" , "linux-mm@kvack.org" , "kyungmin.park@samsung.com" , "linux-arm-kernel@lists.infradead.org" , "m.szyprowski@samsung.com" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org Hi, KyongHo Cho 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 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 --- 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; }