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: 10877 Return-Path: X-Original-To: patchwork@peony.canonical.com Delivered-To: patchwork@peony.canonical.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by peony.canonical.com (Postfix) with ESMTP id B18FF23E02 for ; Wed, 22 Aug 2012 13:37:35 +0000 (UTC) Received: from mail-iy0-f180.google.com (mail-iy0-f180.google.com [209.85.210.180]) by fiordland.canonical.com (Postfix) with ESMTP id 9F5F7A18D33 for ; Wed, 22 Aug 2012 13:37:23 +0000 (UTC) Received: by iadj38 with SMTP id j38so850973iad.11 for ; Wed, 22 Aug 2012 06:37:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-forwarded-to:x-forwarded-for:delivered-to:received-spf :x-pgp-universal:from:to:date:thread-topic:thread-index:message-id :references:in-reply-to:accept-language:x-ms-has-attach :x-ms-tnef-correlator:x-nvconfidentiality:acceptlanguage :mime-version:cc:subject:x-beenthere:x-mailman-version:precedence :list-id:list-unsubscribe:list-archive:list-post:list-help :list-subscribe:content-type:content-transfer-encoding:sender :errors-to:x-gm-message-state; bh=P3oqP09s1685i0eJt9CWBCYaHOIEe6La8eF4xxN5OTA=; b=FzTvqC8ze/2agB5dfou4WSVtv1y1Y9yL5TbSe4GMm4lTkiJzc96/dvRJJNd+nm4cya CuDPTjQiv9oDyh04ANASL5NWwRBVa/8rwdrfopFNSrTkYvCMJwUtb9unaZ/BidOMB0f/ GTfVBXSivKow0JyccksYvwWI/o2tW8/Q47LI710eqlNYkjO/rH2vazBw/UfvSHUcrgW3 t9BW7khEC94lRJCbclzRGVv0b0kLLSdOt55q4DMGuwqy/VPkD1C0q6uULCexjHqOMgDI hnJ4R1DPdFJM2NMApXdfX9nRDxL9aXJ1ImFCRw9rGDtkqe3xP7XN8lv7z9/rnYsXamfG 8KZQ== Received: by 10.42.109.194 with SMTP id m2mr14048725icp.48.1345642654418; Wed, 22 Aug 2012 06:37:34 -0700 (PDT) X-Forwarded-To: linaro-patchwork@canonical.com X-Forwarded-For: patch@linaro.org linaro-patchwork@canonical.com Delivered-To: patches@linaro.org Received: by 10.50.184.232 with SMTP id ex8csp203084igc; Wed, 22 Aug 2012 06:37:33 -0700 (PDT) Received: by 10.204.148.82 with SMTP id o18mr6473555bkv.41.1345642652604; Wed, 22 Aug 2012 06:37:32 -0700 (PDT) Received: from mombin.canonical.com (mombin.canonical.com. [91.189.95.16]) by mx.google.com with ESMTP id hw3si2624706bkc.35.2012.08.22.06.37.27; Wed, 22 Aug 2012 06:37:32 -0700 (PDT) Received-SPF: neutral (google.com: 91.189.95.16 is neither permitted nor denied by best guess record for domain of linaro-mm-sig-bounces@lists.linaro.org) client-ip=91.189.95.16; Authentication-Results: mx.google.com; spf=neutral (google.com: 91.189.95.16 is neither permitted nor denied by best guess record for domain of linaro-mm-sig-bounces@lists.linaro.org) smtp.mail=linaro-mm-sig-bounces@lists.linaro.org Received: from localhost ([127.0.0.1] helo=mombin.canonical.com) by mombin.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1T4B7d-0000kc-Kt; Wed, 22 Aug 2012 13:37:25 +0000 Received: from hqemgate04.nvidia.com ([216.228.121.35]) by mombin.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1T4B7c-0000kT-5M for linaro-mm-sig@lists.linaro.org; Wed, 22 Aug 2012 13:37:24 +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 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 Cc: "linux@arm.linux.org.uk" , "arnd@arndb.de" , "konrad.wilk@oracle.com" , "minchan@kernel.org" , "linux-kernel@vger.kernel.org" , "linaro-mm-sig@lists.linaro.org" , "linux-mm@kvack.org" , "kyungmin.park@samsung.com" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [Linaro-mm-sig] [RFC 2/4] ARM: dma-mapping: IOMMU allocates pages from pool with GFP_ATOMIC X-BeenThere: linaro-mm-sig@lists.linaro.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Unified memory management interest group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linaro-mm-sig-bounces@lists.linaro.org Errors-To: linaro-mm-sig-bounces@lists.linaro.org X-Gm-Message-State: ALoCoQncC7OyDm5c5W9tkPj09XBQFDF/qhWEjxbwj5wmI0Le73g1SZnkWxuq4mOTHr17GbRqw0gI 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; }