Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8034966imu; Tue, 4 Dec 2018 01:38:47 -0800 (PST) X-Google-Smtp-Source: AFSGD/VyTe59HKZbuV4bfA6MrgxwG1KpfHGV8HZZRPP0h2KwrxmwB8K6WCUy75ZhP2tZWj8UsdBy X-Received: by 2002:a17:902:380c:: with SMTP id l12mr18865555plc.326.1543916327558; Tue, 04 Dec 2018 01:38:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543916327; cv=none; d=google.com; s=arc-20160816; b=me/NhwBCYHOlolsKcv8wMQ3i1OGMZRcnyRE4Bl4UfwqnOsAGbaNDKKXRIj2k2anSyQ ciLa83aGHfvfC4PG8/cuwuAXMhweQ0SXOiF3j1IVPLf+mVLjPwac//ajfK358vwbf5k6 +QPl7MobwX6oAa4X3TvuBT0Vw5FyCJk2t5GkRg4wrkOHuHcD6d60NE1e0y6zsUmVyFj0 STypWf4lrnGqQ/1pcdqlqaW0oDCdvRmT0eK4319K8x0EDx86RvcMB75iuDfKFd5KX8wl 5bzmr60+uJ1Ct5D+i2KlyzmKUD+YKX4ydiP/SlehnZiDZVa1cvncirTFuVAipfgO0HE2 HGdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Jxu65MuZDQD/oVINYAKaqUGGlfdLXfq3cyugvKlk2g0=; b=AmsbQ3uBuRnmu6Q20WH0V+anczvJ3B/PHGmfKD4mwiw65HKZ2EEsApUE96qbzW7PZs iprQ2kA4GFmei4vlx3Uw/1VW9BjFBaS7hr7jW8W7SsCfG8cVjPUoNy/PAj76fvj3VmWU x8icSJe7LKPg+nlSZxEhtTmKUblevI1h4eu8gAQBXvfr6Qn0kHv8HkaptBRZrDt3flqk fUNk1IElhxGIeJtakGXYnNbFRqNfT+1sy8aicaOgqqOvEC88B8vAxO3r7ZIRkz24+2wG batk08kqPY+nsSk0eOcIa/uNjiLcau7rjTniVxeAX0Fh+7AIFUyRqKa9EJWV3kifCw58 7/LQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=FLd7ADZX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l30si6265683plg.113.2018.12.04.01.38.32; Tue, 04 Dec 2018 01:38:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=FLd7ADZX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725997AbeLDJh0 (ORCPT + 99 others); Tue, 4 Dec 2018 04:37:26 -0500 Received: from mail-pl1-f194.google.com ([209.85.214.194]:40246 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725834AbeLDJh0 (ORCPT ); Tue, 4 Dec 2018 04:37:26 -0500 Received: by mail-pl1-f194.google.com with SMTP id u18so8014799plq.7 for ; Tue, 04 Dec 2018 01:37:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jxu65MuZDQD/oVINYAKaqUGGlfdLXfq3cyugvKlk2g0=; b=FLd7ADZXlJwebvf6xsGa/j3V2NISFRiwJB5Yj/hrHrjyFRHTJOsF/LSez61ktQ//yB qMy/EV/wforoDAgd5BJjZvpmJmC8GlvBOYRcgcMYrzUjWNE74AW77gBQJOAJFnXCRV/P byamuJgG1WMWSIoydjhNvtzOdbSGfH4/5nick= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jxu65MuZDQD/oVINYAKaqUGGlfdLXfq3cyugvKlk2g0=; b=iVjE/uQrAPHRKcU9iIuyO915GXS7Pwn1VwwcC6Jh3MnA73dyXMfw6r1AYjH3y5uTVu Kdrxty41oFT7kvTerMTyRLgCiaIK7IKpahrOm2BK1OoDrFMoGF5JeDYG+31GCR58QsV5 7t00HTbH9pGxU4o0PKiwE+Nm1alF7xrOONv/HZ2eZ7spi47IsL22I2DowbU1nlURm7+I zFg0Toeaa9um0RBrY+dzePY9heCpZXy/Fs0eY0onMCJzfaq7tXuccLd3/scnzoEXQ1aT z6DrBXzrW6z/0K+HpFSuJj5gJG0AyNS21wtL1UBQLP59S0kaS0Ub3B06aJslb8o+VR0B 2IOg== X-Gm-Message-State: AA+aEWaTvwWWEi7TOBczbl0XbSxDY4RFhKHDnumpGhHVvcrDxmPWrCfU riH4YHM7PUJwVMhRN2v+4GdIeX/1O0OuvB+DmDkO4g== X-Received: by 2002:a17:902:b68d:: with SMTP id c13mr19379871pls.102.1543916244988; Tue, 04 Dec 2018 01:37:24 -0800 (PST) MIME-Version: 1.0 References: <20181111090341.120786-1-drinkcat@chromium.org> In-Reply-To: <20181111090341.120786-1-drinkcat@chromium.org> From: Nicolas Boichat Date: Tue, 4 Dec 2018 17:37:13 +0800 Message-ID: Subject: Re: [PATCH v2 0/3] iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables To: Robin Murphy , Christoph Lameter , Vlastimil Babka , Michal Hocko , Matthias Brugger , hch@infradead.org, Matthew Wilcox Cc: Will Deacon , Joerg Roedel , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Mel Gorman , Levin Alexander , Huaisheng Ye , Mike Rapoport , linux-arm Mailing List , iommu@lists.linux-foundation.org, lkml , linux-mm@kvack.org, Yong Wu , Tomasz Figa , yingjoe.chen@mediatek.com, Hsin-Yi Wang , Daniel Kurtz Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 11, 2018 at 5:04 PM Nicolas Boichat wrote: > > This is a follow-up to the discussion in [1], to make sure that the page > tables allocated by iommu/io-pgtable-arm-v7s are contained within 32-bit > physical address space. > > [1] https://lists.linuxfoundation.org/pipermail/iommu/2018-November/030876.html Hi everyone, Let's try to summarize here. First, we confirmed that this is a regression, and IOMMU errors happen on 4.19 and linux-next/master on MT8173 (elm, Acer Chromebook R13). The issue most likely starts from ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32"), i.e. 4.15, and presumably breaks a number of Mediatek platforms (and maybe others?). We have a few options here: 1. This series [2], that adds support for GFP_DMA32 slab caches, _without_ adding kmalloc caches (since there are no users of kmalloc(..., GFP_DMA32)). I think I've addressed all the comments on the 3 patches, and AFAICT this solution works fine. 2. genalloc. That works, but unless we preallocate 4MB for L2 tables (which is wasteful as we usually only need a handful of L2 tables), we'll need changes in the core (use GFP_ATOMIC) to allow allocating on demand, and as it stands we'd have no way to shrink the allocation. 3. page_frag [3]. That works fine, and the code is quite simple. One drawback is that fragments in partially freed pages cannot be reused (from limited experiments, I see that IOMMU L2 tables are rarely freed, so it's unlikely a whole page would get freed). But given the low number of L2 tables, maybe we can live with that. I think 2 is out. Any preference between 1 and 3? I think 1 makes better use of the memory, so that'd be my preference. But I'm probably missing something. [2] https://patchwork.kernel.org/cover/10677529/, 3 patches [3] https://patchwork.codeaurora.org/patch/671639/ Thanks, Nicolas