Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp12378888imu; Tue, 1 Jan 2019 22:24:29 -0800 (PST) X-Google-Smtp-Source: ALg8bN4vW1k7DA6VXEJklcDYBzoHys4Z2Ie3DVHtsP0t3drUTcMDBj3tDMr6LAlCcIVzObC572Fq X-Received: by 2002:a65:6215:: with SMTP id d21mr12623897pgv.289.1546410269525; Tue, 01 Jan 2019 22:24:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546410269; cv=none; d=google.com; s=arc-20160816; b=zXUT05uDarNGhn99uclRs0RNIPuIuXN+NXmg75AHxE/Bs8OBKIy3uMmc4RoCGdbNYO i8Xtj7I0PE6FZNoeHpvWbMns2i++vWavDBkUCJLzidEpQbhrFdZFSzpk3XFwxkl3kFFi gI9G/yZZwpa/St1G7dOO2kkYNEtnoV5qFNoewDXexAVH9ApGdHIC1ZPNOm39mxEAQ9bw iVmomV7K2Yu5PPnT/9ndsRJvDKzNUOh0ODq0r8Kai9lVBHpaO0SogukqzJ0CjJSeENv9 kPmDcGwXsihMiakD4Jh7fYjZ+5lXYxBBHp3CwEGekO6Gn97jTMK7uM6YJ/xXJH0FuE3X GWAA== 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=/RT2abgqnBKCQ74QwzoyIyU7Rv/U52C3iy99nR44H5o=; b=Fw+ZW91/bb/DaTxkdy3lHEZBbYpY7VCy3EPvqZccicxDETOXOL3XUSlgOjD4iQGji4 3r5f1OQLQ/ctyGWxI4ATMymr3wmXOJWsq8LQ5Kzmbo1ywHEboUC/ffPgVaWp1zhMIXFy aLI9q3KpaHfSi0q+vbETc1xyANe1Rl2iF8ZV9I4lK1L5UJBB6CGBpq5575h01HkP9kev Rsa66/EsMgnrxOLer2cv3DvxVY2dt4nLQBKdVi5ZSm1kh1xYQC5wiV17T3eG6wuFq/wI bVKsTETRgm9s1zkW2tjP9FB1q0e4Y6cTRBJfeWJk4EziR9ICz2YkWMbEf968VHmhhOly iG1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=m1NoC2Hq; 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 c76si5967287pga.70.2019.01.01.22.24.12; Tue, 01 Jan 2019 22:24:29 -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=m1NoC2Hq; 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 S1728475AbfABFv7 (ORCPT + 99 others); Wed, 2 Jan 2019 00:51:59 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:41094 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726294AbfABFv6 (ORCPT ); Wed, 2 Jan 2019 00:51:58 -0500 Received: by mail-qt1-f193.google.com with SMTP id l12so32445868qtf.8 for ; Tue, 01 Jan 2019 21:51:56 -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=/RT2abgqnBKCQ74QwzoyIyU7Rv/U52C3iy99nR44H5o=; b=m1NoC2HqsQfyDG3eQXWCxZiWnU2XjiZIpTQPa+5vsHI3mqNz1EftTooPlMZQlxFfZ8 JZ2zSWtwWl2/Z84PqKsLn35wscF4HMwRIE5ZiM/gSS87W9A2VP3RnRkgCRuFUxzuEw39 3U+ycyEya+PCJmp8aBL4QQPSPNy+QlQHisk2M= 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=/RT2abgqnBKCQ74QwzoyIyU7Rv/U52C3iy99nR44H5o=; b=sheYfddiQBsFZriDMBOjq6L9cEcOvdB/0QLM3WqPuV+8RnUSjDr9sjX+C3sliTBQgW qB9Rb4K/YL+nxNEkuduHx2pHKUfiaCaIe+hzl7/2i2RuaYxkm1Etv+yT0mvEYkQSWHKL qIa0Ey5veL2FNAaIDnvDDDR7OPUJ25+IVNGB3bufba8CrzdRwuEMsqcO7/mvlAZxf1xd pCvflwSzu9Ch+QDeC+zGIW1LTusoLwbGLBLqEhwgvWWtwx4Uu1EUum077+ezNJMP7PXO ZsX4mClwDTHeZV6JsHGN4ryy1MSDUFlxBO9jRwzi3RT6UbOQ5oRyUyq8iTs9Ibpl6LX9 dduQ== X-Gm-Message-State: AA+aEWbilIDiCkL2ZhNHUfGH21y9k19fGkKyLjkvMvd/thnLn6REPMI4 tAVSYqyMMs/Z0qRKfzdtqU6+EMDobhKJRUzzrbITPg== X-Received: by 2002:ac8:6b50:: with SMTP id x16mr42135783qts.368.1546408316297; Tue, 01 Jan 2019 21:51:56 -0800 (PST) MIME-Version: 1.0 References: <20181210011504.122604-1-drinkcat@chromium.org> In-Reply-To: <20181210011504.122604-1-drinkcat@chromium.org> From: Nicolas Boichat Date: Wed, 2 Jan 2019 13:51:45 +0800 Message-ID: Subject: Re: [PATCH v6 0/3] iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables To: Will Deacon , Andrew Morton Cc: Robin Murphy , Joerg Roedel , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Michal Hocko , Mel Gorman , Levin Alexander , Huaisheng Ye , Mike Rapoport , linux-arm Mailing List , iommu@lists.linux-foundation.org, lkml , linux-mm@kvack.org, Yong Wu , Matthias Brugger , Tomasz Figa , Yingjoe Chen , hch@infradead.org, Matthew Wilcox , Hsin-Yi Wang , stable@vger.kernel.org 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 Hi all, On Mon, Dec 10, 2018 at 9:15 AM Nicolas Boichat wrote: > > This is a follow-up to the discussion in [1], [2]. > > IOMMUs using ARMv7 short-descriptor format require page tables > (level 1 and 2) to be allocated within the first 4GB of RAM, even > on 64-bit systems. > > For L1 tables that are bigger than a page, we can just use __get_free_pages > with GFP_DMA32 (on arm64 systems only, arm would still use GFP_DMA). > > For L2 tables that only take 1KB, it would be a waste to allocate a full > page, so we considered 3 approaches: > 1. This series, adding support for GFP_DMA32 slab caches. > 2. genalloc, which requires pre-allocating the maximum number of L2 page > tables (4096, so 4MB of memory). > 3. page_frag, which is not very memory-efficient as it is unable to reuse > freed fragments until the whole page is freed. [3] > > This series is the most memory-efficient approach. Does anyone have any further comment on this series? If not, which maintainer is going to pick this up? I assume Andrew Morton? Thanks, > stable@ note: > 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 commit ad67f5a6545f ("arm64: replace ZONE_DMA > with ZONE_DMA32"), i.e. 4.15, and presumably breaks a number of Mediatek > platforms (and maybe others?). > > [1] https://lists.linuxfoundation.org/pipermail/iommu/2018-November/030876.html > [2] https://lists.linuxfoundation.org/pipermail/iommu/2018-December/031696.html > [3] https://patchwork.codeaurora.org/patch/671639/ > > Changes since v1: > - Add support for SLAB_CACHE_DMA32 in slab and slub (patches 1/2) > - iommu/io-pgtable-arm-v7s (patch 3): > - Changed approach to use SLAB_CACHE_DMA32 added by the previous > commit. > - Use DMA or DMA32 depending on the architecture (DMA for arm, > DMA32 for arm64). > > Changes since v2: > - Reworded and expanded commit messages > - Added cache_dma32 documentation in PATCH 2/3. > > v3 used the page_frag approach, see [3]. > > Changes since v4: > - Dropped change that removed GFP_DMA32 from GFP_SLAB_BUG_MASK: > instead we can just call kmem_cache_*alloc without GFP_DMA32 > parameter. This also means that we can drop PATCH v4 1/3, as we > do not make any changes in GFP flag verification. > - Dropped hunks that added cache_dma32 sysfs file, and moved > the hunks to PATCH v5 3/3, so that maintainer can decide whether > to pick the change independently. > > Changes since v5: > - Rename ARM_V7S_TABLE_SLAB_CACHE to ARM_V7S_TABLE_SLAB_FLAGS. > - Add stable@ to cc. > > Nicolas Boichat (3): > mm: Add support for kmem caches in DMA32 zone > iommu/io-pgtable-arm-v7s: Request DMA32 memory, and improve debugging > mm: Add /sys/kernel/slab/cache/cache_dma32 > > Documentation/ABI/testing/sysfs-kernel-slab | 9 +++++++++ > drivers/iommu/io-pgtable-arm-v7s.c | 19 +++++++++++++++---- > include/linux/slab.h | 2 ++ > mm/slab.c | 2 ++ > mm/slab.h | 3 ++- > mm/slab_common.c | 2 +- > mm/slub.c | 16 ++++++++++++++++ > tools/vm/slabinfo.c | 7 ++++++- > 8 files changed, 53 insertions(+), 7 deletions(-) > > -- > 2.20.0.rc2.403.gdbc3b29805-goog >